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Foreword 

This Technical Specification has been produced by the 3"* Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

IMS Centralized Services (ICS) enable the delivery of IM CN subsystem based multimedia telephony and 
supplementary services as defined in 3GPP TS 24.173 [4] to users regardless of the attached access network type; e.g. 
CS domain access or IP-CAN. 

The present document specifies the principles of interworking between the IM CN subsystem and CS domain in order 
to enable ICS for UEs using CS domain access. 

The present document addresses the area of registration procedures interworking between the CS domain and IM CN 
subsystem. 

The present document addresses the areas of control and user plane interworking between the IM CN subsystem and CS 
domain through an MSC Server enhanced for ICS and CS-MGW respectively. This includes the signalling procedures 
between the MSC Server and CS-MGW. For the specification of control plane interworking, present document defines 
the protocol interworking between the 3GPP profile of SIP as described in 3GPP TS 24.229 [2] and NAS signalling as 
described in 3GPP TS 24.008 [3] required for the support of IM CN subsystem based multimedia telephony and 
supplementary services. 

The present document addresses the area of supplementary service configuration interworking between the CS domain 
and IM CN subsystem. 

The present document is applicable to the MSC Server and CS-MGW. 



2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 



• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 



[1] 


3GPP TR 21.905: 


"Vocabulary for 3GPP Specifications". 


[2] 


3GPP TS 24.229: 


"IP Multimedia Call Control Protocol based on SIP and SDP". 


[3] 


3GPP TS 24.008: 


"Mobile radio interface layer 3 specification; Core Network protocols; Stage 3". 


[4] 


3GPPTS 24.173: 

Stage 3". 


"IMS multimedia telephony communication service and supplementary services; 


[5] 


3GPP TS 23.292: 


"IP Multimedia Subsystem (IMS) Centralized Services; Stage 2". 


[6] 


3GPPTS 23.002: 


"Network Architecture". 


[7] 


3GPP TS 24.292: 
Stage 3". 


"IP Multimedia (IM) Core Network (CN) subsystem CentraUzed Services (ICS); 


[8] 


3GPPTS 23.018: 


"Basic call handUng; Technical reaUzation". 


[9] 


3GPPTS 22.003: 


"Circuit Teleservices supported by a Public Land Mobile Network (PLMN)". 


[10] 


3GPPTS 23.003: 


"Numbering, addressing and identification". 


[11] 


3GPP TS 29.232: 
3". 


"Media Gateway Controller (MGC) - Media Gateway (MGW) interface; Stage 
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[12] 3GPP TS 24.081: "Line Identification Supplementary Services - Stage 3". 

[13] Void 

[14] 3GPP TS 24.608: "Terminating Identification Presentation (TIP) and Terminating Identification 

Restriction (TIR) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol 
specification". 

[15] 3GPP TS 25.414: "UTRAN lu interface data transport and transport signalling". 

[16] 3GPP TS 25.415: "UTRAN lu interface user plane protocols". 

[17] 3GPP TS 25.411: "UTRAN lu interface layer 1". 

[18] 3GPP TS 29.414: "Core network Nb data transport and transport signalling". 

[19] 3GPP TS 48.004: "Base Station System - Mobile-services Switching Centre (BSS - MSC) 

interface; Layer 1 specification". 

[20] 3GPP TS 29.002: "Mobile AppUcation Part (MAP) specification". 

[21] 3GPP TS 26.235: "Packet switched conversational multimedia applications; Default codecs". 

[22] 3GPP TS 26.226: "CTM Cellular Text telephony Modem, General description" . 

[23] 3GPP TS 24.604: "Conmiunication Diversion (CDIV) using IP Multimedia (IM) Core Network 

(CN) subsystem; Protocol specification". 

[24] 3GPP TS 24.082: "Call Forwarding (CF) supplementary services; Stage 3". 

[25] 3GPP TS 24.072: " Call Deflection (CD) Supplementary Service; Stage 3". 

L26J 3GPP TS 24.083: "Call Waiting (CS) and Call Hold (HOLD) supplementary services; Stage 3". 

[27] 3GPP TS 24.610: "Communication HOLD (HOLD) using IP Multimedia (IM) Core Network 

(CN) subsystem; Protocol specification". 

[28] 3GPP TS 26.1 14: "IP Multimedia Subsystem (IMS); Multimedia Telephony; Media handUng and 

interaction". 

[29] 3GPP TS 24.080: "Mobile radio interface layer 3 supplementary services specification; Formats 

and coding". 

[30] 3GPP TS 24.088: "Call Barring (CB) Supplementary Service - Stage 3". 

[31] 3GPP TS 24.61 1: "Anonymous Communication Rejection (ACR) and Communication Barring 

(CB); using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification". 

[32] 3GPP TS 24.09 1 : "Explicit Call Transfer (ECT) supplementary service; Stage 3 " . 

[33] 3GPP TS 24.629: "Explicit Communication Transfer (ECT) using IP Multimedia (IM) Core 

Network (CN) subsystem; Protocol specification". 

[34] 3GPP TS 24.084: "Multi Party (MPTY) supplementary service - Stage 3 " . 

[35] 3GPP TS 24.605: "Conference (CONF) using IP Multimedia (IM) Core Network (CN) subsystem; 

Protocol specification ". 

[36] 3GPP TS 24. 147: " Conferencing using the IP Multimedia (IM) Core Network (CN) subsystem; 

Stage 3". 

[37J 3GPP TS 23.009: "Handover procedures". 

[38] 3GPP TS 48.103: "Base Station System - Media GateWay (BSS-MGW) interface; User Plane 

transport mechanism". 

[39] 3GPP TS 23 .205 : "Bearer Independent switched core network; Stage 2" . 
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[40] 3GPP TS 23.231: "SIP-I based circuit-switched core network; Stage 2". 

[41] 3GPP TS 24.010: "Mobile radio interface layer 3 Supplementary services specification; General 

aspects". 

[42] 3GPP TS 24.623: "Extensible Markup Language (XML) Configuration Access Protocol (XCAP) 

over the Ut interface for Manipulating Supplementary Services". 

[43] 3GPP TS 24.607: "Originating Identification Presentation (OIP) and Originating Identification 

Restriction (OIR) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol 
specification". 

[44] 3GPP TS 24.615: "Communication Waiting (CW) using IP Multimedia (IM) Core Network (CN) 

subsystem; Protocol specification". 

[45] IETF RFC 3326: "The Reason Header Field for the Session Initiation Protocol (SIP)". 

[46] 3GPP TS 29. 163: "Interworking between the IP Multimedia (IM) Core Network (CN) subsystem 

and Circuit Switched (CS) networks". 

[47] IETF RFC 5009: "Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for 

Authorization of Early Media". 

[48] IETF RFC 3168: "The Addition of Explicit Congestion Notification (ECN) to IP". 

[49] IETF draft-ietf-avtcore-ecn-for-rtp-05: "Explicit Congestion Notification (ECN) for RTP over 

UDP". 

Editor's Note: The above document cannot be formally referenced until it is published as an RFC. 

[50] IETF RFC 3959: "The Early Session Disposition Type for the Session Initiation Protocol (SIP)". 

[51] 3GPP TS 24.182: "IP Multimedia Subsystem (IMS) Customized Alerting Tones (CAT); Protocol 

specification ". 

3 Definitions and abbreviations 
3.1 Definitions 



For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP 
TR 21.905 [1]. 

NAS signalling: layer 3 signalling carried over CS domain access between the UE and MSC Server as defined in 
3GPPTS 24.008 [3]. 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 24.629 [33] apply: 

transferee 
transferor 
transfer target 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPP TR 21.905 [1]. 

3PCC 3"* Party Call Control 

CB Communication Barring 

CD Communication Deflection 
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CDIV 


Communication Diversion 


CDIVN 


Communication Diversion Notification 


CFNL 


Communication Forwarding on Not Logged-in 


CFNR 


Communication Forwarding No Reply 


CFNRc 


Communication Forwarding on subscriber Not Reachable 


CFU 


Communication Forwarding Unconditional 


CONF 


CONFerence 


CS 


Circuit Switched 


CS-MGW 


Circuit Switched Media Gateway 


ECN 


Exphcit Congestion Notification 


ECT 


ExpUcit Communication Transfer 


GRUU 


Globally Routable User Agent URI 


HOLD 


communication HOLD 


ICB 


Incoming Communication Biirring 


ICS 


IM CN subsystem Centralized Services 


IMS-MGW 


IP Multimedia Subsystem-Media Gateway Function 


luFP 


lu Framing Protocol 


MboIP 


Mb over IP 


MRFP 


Media Resource Function Processor 


NAS 


Non Access Stratum 


OCB 


Outgoing Communication Barring 


OIP 


Originating Identification Presentation 


OIR 


Originating Identification Restriction 


RTCP 


RTP Control Protocol 


TDM 


Time Division Multiplex 


TIP 


Terminating Identification Presentation 


TIR 


Terminating Identification Restriction 



4 Interworking overview 
4.1 Interworking reference model 

Figure 4.1.1 details the reference model required to support interworking between the 3GPP IM CN subsystem and CS 
domain access for IM basic voice calls and supplementary services. 



AMuCS 



GERAN/ 
UTRAN 



MSG Server 
enhanced for 
ICS 



Mc 



AMuCS 

Control plane 
User plane 



CSCF 



CS-MGW 


Mb 


(N0TE2) 







NOTE 1 : The logical split of the signalling and bearer path between the CS access network and MSG Server 

enhanced for ICS Is as shown; however, the signalling and bearer may be directly connected to the MGW. 

NOTE 2: The CS-MGW may be connected via the Mb reference point to various network entities, such as a UE (via 
a GTP tunnel to a GGSN), an MRFP, or an IMS-MGW, or a remote CS-MGW. 

Figure 4.1.1 : MSC Server - iiUI CN subsystem interworlcing reference model 
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4.2 Interworking reference points and interfaces 

The reference points and network interfaces shown in figure 4.1.1 are as described: 
A reference point: The A reference point is defined in 3GPP TS 23.002 [6]. 
luCS reference point: The luCS reference point is defined in 3GPP TS 23.002 [6]. 

12 reference point: The call control protocol specified in this document for use on the 12 reference point (i.e. between 
MSG Server enhanced for IGS and GSGF) is based on Mw reference point as defined in 3GPP TS 23.002 [6] and the 
3GPP profile of SIP as defined in accordance with 3GPP TS 24.229 [2]. 

Mc reference point: The Mc reference point is defined in 3GPP TS 23.002 [6]. 

Mb reference point: The Mb reference point is defined 3GPP TS 23.002 [6]. 

4.3 Interworking functional entities 

4.3.1 IVISC Server enhanced for ICS 

This is the component which provides the interworking between CS domain access and IM CN subsystem control 
planes, and it shall support the functions as defined in accordance with 3GPP TS 23.002 [6]. 

For brevity, where the term "MSG Server" is used in the rest of the specification, this shall be imderstood as "MSG 
Server enhanced for IGS". 

4.3.2 Circuit Switched IVIedia Gateway Function (CS-IVIGW) 

This is the component which provides the interworking between GS domain access and IM GN subsystem user planes, 
and it shall support the functions as defined in accordance with 3GPP TS 23.002 [6]. 

4.4 Control plane interworking 

Within the IM GN subsystem, the 3GPP profile of SIP defined in 3GPP TS 24.229 [2] is used for session control. 

Over GS domain access, NAS signalling is used for call origination, call termination and supplementary services. 

Therefore, in order to provide the required interworking to enable IGS for UE using GS domain access, the control 
plane protocols shall be interworked within the MSG Server. 

4.5 User plane interworking 

Within the IM GN subsystem, framing protocols such as RTP are used to transport media packets to and from IM GN 
subsystem entities such as the UE, MRFP or IMS-MOW. 

GS domain access uses circuit switched bearer channels like TDM circuits (e.g. 64kbits PGM), ATM/AAL2 circuits or 
IP bearers using the luFP framing protocol or RTP to carry voice frames. 

Therefore, in order to provide the required interworking to enable IGS for a UE using GS domain access, the user plane 
protocols shall be interworked within the GS-MGW, under the control of the MSG Server. 
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5 Control plane procedures and interworking 
5.1 General 

The following subclauses define the procedures and signalling interworking performed by the MSC Server to enable 
ICS for UEs attached to the CS domain. The interworking between NAS signalling and the Session Initiation Protocol 
(SIP) with its associated Session Description Protocol (SDP) is specified. 

The capabilities of SIP and SDP that are interworked with NAS signalling are defined in 3GPP TS 24.229 [2]. 
Table 5.1.1 lists the service interworking within the scope of the present document. 

Table 5.1.1: Interworking between NAS signalling and SIP/SDP 

Telephony or Supplementary Service 

TS1 1 non-emergency speech calls 
Originating Identification Presentation (OIP) 
Originating Identification Restriction (OIR) 
Terminating Identification presentation (TIP) 
Terminating Identification restriction (TIR) 
Communication Hold and Resume 
Communication Waiting 
Communication Barring 
Communication Diversion 
Explicit Communication Transfer 
Conferencing 



5.2 IMS registration procedures interworking 

5.2.1 Initial registration 

Upon successful completion of the location updating procedure as specified in 3GPP TS 24.008 [3], an MSC Server 
supporting the ICS Indicator parameter as specified in 3GPP TS 29.002 [20] shall determine whether to perform initial 
IMS registration on behalf of the UE. 

The relevant location update case, when an initial registration is needed to the IM CN subsystem is a location update to 
new MSCA^LR service area (the MSCA^LR was not the previous serving network element). 

In accordance with 3GPP TS 23.292 [5], subclause 7.2.1.1, the MSC Server may perform an initial IMS registration. 
The optional flag referred to in subclause 7.2.1.1 of 3GPP TS 23.292 [5] is implemented as the ICS Indicator parameter 
in3GPPTS 29.002 [20]. 

When performing initial IMS registration, the MSC Server shall send a REGISTER request on behalf of the UE as 
described in 3GPP TS 24.292 [7]. 

5.2.2 Reregistration 

The MSC Server shall initiate reregistration for a previously registered Public User Identity as described in 3GPP TS 
24.292 [7] if that subscriber is still registered in the MSC Server via CS domain access. 
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5.2.3 MSG Server initiated deregistration 

The MSG Server shall send a REGISTER request for deregistration on behalf of the UE as described in 3GPP TS 
24.292 [7] upon receipt of any indication that the subscriber is no longer registered in this MSG Server. 

Prior to sending a REGISTER request for deregistration, the MSG Server shall release all IMS dialogs related to the 
Public User Identity that is going to be deregistered or to one of the implicitly registered Pubhc User Identities. 

5.3 Interworking of mobile originating call setup from NAS 
signalling to SIP 

5.3.1 General 

The mobile originating call shall be estabUshed in accordance with 3GPP TS 23.018 [8] and 3GPP TS 24.008 [3]. The 
IM GN subsystem originating session shall be established in accordance with 3GPP TS 24.292 [7] and 3GPP TS 24.229 
[2]. The following subclauses describe the additional requirements for interworking between NAS signalling and SIP. 

The following subclauses also assume the originating call is received from a subscriber with an active IM GN 
subsystem registration via the MSG Server performing the interworking. 

5.3.2 Receipt of a setup message 

Upon receipt of a setup message (a SETUP message or an EMERGENGY SETUP message), the MSG Server shall 
determine whether the originating call shall be directed to the IM GN subsystem. 

The originating call shall be directed to the IM GN subsystem if all of the following conditions are met: 

- the setup message is a SETUP message and is determined by the MSG Server not to be an emergency call, and 
the bearer capability 1 information element indicates teleservice 1 1 as described in 3GPP TS 22.003 [9], and 

- the GTM text telephony indication in the bearer capability 1 information element is set to "GTM text telephony 
is not supported", and 

the bearer capability 2 information element is not present. 
Otherwise the originating call shall be handled by the MSG Server without interworking to the IM GN subsystem. 

5.3.3 Sending of INVITE 

5.3.3.1 General 

Upon determining that an incoming SETUP message shall be interworked to the IM GN subsystem, the MSG Server 
shall generate an INVITE request as further detailed in the subclauses below. 

5.3.3.2 Coding of INVITE 

The INVITE request shall be coded as described in 3GPP TS 24.292 [7J with the following SETUP message 
interworking apphed: 

- The called party BGD number information element in the SETUP message is used to derive the Request URI of 
the INVITE request as follows: 

if the type of number field is set to "international number", then the number digit fields, prefixed with a "+", 
shall be used to build a tel URI or a SIP URI with "user=phone"; or 

- if the type of number field is set to "national number", then the MSG Server shall either: 

convert the number to international format by prefixing the number digits with "+GG" and use this to 
build a tel URI or a SIP URI with "user=phone"; or 
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NOTE 1 : CC is the country code of the network in which the MSG Server is located. 

- use the number digit fields to build a tel URI or a SIP URI with "user=phone". The phone-context 

parameter shall include the home network domain name defined for IMS centralized services in 3GPP TS 
23.003 [10]. For geo-local numbers, the home domain name shall be prefixed by the "geo-local" string 
according to 3GPP TS 24.229 [2]. 

NOTE 2: The manner in which the MSG Server distinguishes between geo-local and home-local numbers is 
implementation specific. 

if the type of number field is set to "unknown", then the MSG Server shall build a SIP URI with 
"user=phone" or a tel URI, including the received digits as an unprocessed dial string to the IM GN 
subsystem, using one of the formats for UEs without dial string processing capabilities, as defined in 3GPP 
TS 24.229 [2], subclause 5.1.2A.1.3; 

NOTE 3: This sets the requirement that the dialling plan is designed so it enables the IM GN subsystem to 
differentiate local numbers from other numbers; refer to subclause 5.1.2A. 1.3. 

if the GLIR invocation information element is present in the SETUP message, the From header shall be set to an 
Anonymous User Identity as defined in 3GPP TS 23.003 [10] and the MSG Server shall include a Privacy header 
with priv- value set to "id"; 

if the GLIR suppression information element is present in the SETUP message, the MSG Server shall include a 
Privacy header with priv- value set to "none"; 

if the GLIR invocation information element and GLIR suppression information element are not present in the 
SETUP message, the MSG Server shall not include a Privacy header; 

- the P-Asserted-ldentity header shall be set to the default public identity received during registration procedures; 

- the Gontact header shall be set to: 

- the public GRUU received at registration as specified in 3GPP TS 24.229 [11]; or 

if the GLIR suppression information element is present in the SETUP message to the temporary GRUU 
received at registration as specified in 3GPP TS 24.229 [11]. 

When a SIP URI is used for the Request URI, the host portion of the SIP URI shall be set to the home network domain 
name defined for IMS centralized services in 3GPP TS 23.003 [10]. 

If the MSG server supports the P-Early-Media header as a network option, then it shall include the header in each 
outgoing SIP INVITE request. 

5.3.3.3 Coding of the SDP offer 

The MSG Server shall determine the speech codecs supported by the UE as specified in 3GPP TS 24.008 [3] and use 
this information when constructing a codec list for the SDP offer. The MSG Server may also add speech codecs. The 
added speech codecs are based on configuration data in the MSG Server. 

If the access bearer establishment has been initiated prior to the sending of the INVITE request (e.g. no speech codec or 
one speech codec is indicated from the originating UE) the MSG Server shall indicate that preconditions have been met 
in the initial SDP offer. The MSG Server may indicate in the bearer establishment procedure to the UE the speech codec 
the UE shall use. 

If access side bearer establishment has not been performed prior to sending the INVITE request, the MSG Server shall 
indicate that preconditions have not been met in the SDP offer. Once access side bearer establishment has been 
performed, the MSG Server shall indicate that preconditions have been met in a new SDP offer in a subsequent 
UPDATE or PRAGK request. 

5.3.3.4 Actions on tine SDP answer 

At the receipt of the SDP answer the MSG Server shall analyse the received speech codecs: 

- If the received speech codecs in the SDP answer do not include any of the speech codecs provided by the UE in 
the SETUP message or the SDP answer only include the default speech codec the MSG Server shall instruct the 
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CS-MGW to perform transcoding and indicate in the bearer establishment procedure to the UE the speech codec 
the UE shall use. Which of the codecs used is based on local policy; 

- if only one speech codec is received in the SDP answer, the MSG Server shall select that speech codec and may 
indicate the speech codec in the bearer establishment procedure to the UE; 

- if more than one speech codec is received in the SDP answer the MSG Server shall select one codec based on 
local configuration and may indicate the speech codec in the bearer establishment procedure to the UE; and send 
a new SDP offer which shall indicate the speech codec that the MSG Server has selected. 

For UTRAN and GERAN lu-mode, the NAS Synchronisation Indicator information element shall be used to inform the 
UE of the selected codec as specified in 3GPP TS 24.008 [3]. 

5.3.4 Sending of ALERTING 

The MSG Server shall send an ALERTING message towards the UE upon receiving the first 180 Ringing response. 

5.3.4a Sending of PROGRESS 

Once all the following conditions have been met: 

1) the MSG server supports the P-Early-Media header field, and received the first SIP 183 Session Progress 
response that includes a P-Early-Media header field authorizing backward early media; 

2) SDP preconditions are not used, or applicable SDP preconditions have been met; and 

3) the MSG server did not receive a SIP 180 Ringing; 
then the MSG server shall send a PROGRESS message. 

5.3.4b Tlirougli-Connecting early media from IIVIS 

If a SIP 18x response is received by the MSG server, once all the following conditions have been met: 

1) the MSG server supports the P-Early-Media header field, and the response includes a P-Early-Media header field 
authorizing backward early media; and 

2) SDP preconditions are not used, or applicable SDP preconditions have been met; 

then the MSG server shall instruct the GS-MGW to through-connect as described in subclause 7.1.5 for early media 
from the IMS side unless the GS-MGW has already been through-connected. 

NOTE: An MSG server supporting the early session model GAT supplementary service applies additional 
procedure described in subclause 5.6.9. 

5.3.5 Applying ringback tone 

The MSG Server shall instruct the GS-MGW to apply ringback tone towards the UE in the following conditions: 

- a 180 Ringing response is received and either: 

- the MSG Server does not support the P-Early-Media header as a network option; or 

the MSG Server supports the P-Early-Media header as a network option and according to IETF REG 5009 
[47] backward early media is not authorized (the most recently received P-Early-Media header does not 
authorize backward early media or the P-Early-Media header has not yet been received). 

5.3.6 Receipt of 200 OK (INVITE) 

Upon receipt of the first 200 OK (INVITE) response, the MSG Server shall: 

- instruct the GS-MGW to stop ringback if ringback was previously applied; and 
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- instruct the CS-MGW to through-connect the bearer in both directions; and 

- send a CONNECT message towards the UE as described in 3GPP TS 24.008 [3] . 
Interworking applied for the TIP service is described in subclause 5.6.2.1. 

The MSC Server shall not progress any further early dialogs to established dialogs. Therefore, upon receipt of a 
subsequent 200 OK final response to the initial INVITE request (e.g. due to forking), the MSC Server shall: 

- acknowledge the response with an ACK request; and 

- send a BYE request to this dialog in order to terminate it. 

5.3.7 Receipt of status-codes 3xx 

Upon receipt of a 3xx response to the initial INVITE, the default behaviour of the MSC Server shall be to release the 
call with a cause code value of 127 (Interworking unspecified). 

NOTE: The MSC Server may also decide to redirect the call toward the URI in the Contact header field of the 
3xx response, as an operator option. Such handling is outside the scope of the present document. 

5.3.8 Receipt of status-codes 4xx, 5xx or 6xx 

If the MSC Server receives a 4xx, 5xx or 6xx response to the initial INVITE and the MSC Server has not sent a 
CANCEL request, it shall initiate call clearing procedures by sending a DISCONNECT message towards the UE as 
described in 3GPP TS 24.008 [3] with the following interworking applied: 

- If one or more Reason headers is included in the 4xx, 5xx or 6xx response, then the cause value of each Reason 
header shall be mapped to a cause information element in the DISCONNECT message as follows: 

- if the Reason header contains a Q.850 cause value, the numeric cause code shall be mapped directly to the 
cause value octet of the cause information element in the DISCONNECT message; or 

- if the Reason header contains a SIP status-code, the coding of the cause information element in the 
DISCONNECT message shall be as follows: 

- set the coding standard to "Standard defined for the GSM PLMNs"; and 

- set the location to "network beyond interworking point"; and 

- derive the cause value from the SIP status-code received in the Reason header according to table 5.3.8.1. 
The 4xx, 5xx, and 6xx SIP responses that are not covered in this table shall be interworked to a cause 
value of 127 (Interworking, unspecified); or 

if no Reason header is included in the 4xx, 5xx or 6xx response, the coding of the cause information element 
in the DISCONNECT message is derived from the SIP status-code of the SIP response according to table 
5.3.8.1, where the following information elements shall be set to; 

- coding standard to "Standard defined for the GSM PLMNs"; and 

- location to "network beyond interworking point". 

Table 5.3.8.1 : Mapping the 4xx/5xx/6xx status-code to the cause information element 



SIP status-code 


Cause value 


400 Bad Request 


127 (lnterworl<ing, unspecified) 


401 Unauthorized 


127 (lntenworl<ing, unspecified) 


402 Payment Required 


127 (Intenworking, unspecified) 


403 Forbidden 


127 (lnterworl<ing, unspecified) 


404 Not Found 


1 (Unassigned (unallocated) number) 
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SIP status-code 


Cause value 


4Uo Meinoa not Allowed 


127 (Interworking, unspecified) 


406 Not Acceptable 


127 (Interworking, unspecified) 


407 Proxy authentication recjuired 


127 (Interworking, unspecified) 


408 Request Timeout 


127 (Interworking, unspecified) 


4 lU oone 


22 (Number changed) 


41 3 Request Entity too long 


127 (Interworking, unspecified) 


414 Request-URI too long 


127 (Interworking, unspecified) 


41 5 Unsupported Media type 


127 (Interworking, unspecified) 


416 Unsupported URI scheme 


127 (Interworking, unspecified) 


420 Bad Extension 


127 (Interworking, unspecified) 


421 Extension required 


127 (Interworking, unspecified) 


4^:o Interval loo bsrier 


127 (Interworking, unspecified) 


433 Anonymity Disallowed 


(Oali rejected) 


480 Temporarily Unavailable 


41 (Temporary Failure) 


481 Oall/Tran^actinn dnP9 not pxi^t 


127 (Interworking, unspecified) 


482 LooD detected 


127 (Interworking, unspecified) 


483 Too manv hon*? 


127 (Interworking, unspecified) 


484 Address Incomplete 


28 (Invalid number format (incomplete 
number)) 


485 Ambiguous 


127 (Interworking, unspecified) 


4ob busy Here 


1 7 (User busy) 


487 Request terminated 


127 (Interworking, unspecified) 


488 Not acceptable here 


127 (Interworking, unspecified) 


493 Undecipherable 


127 (Interworking, unspecified) 


500 Server Internal error 


127 (Interworking, unspecified) 


501 Not implemented 


127 (Interworking, unspecified) 


oUi! baa oateway 


127 (Interworking, unspecified) 


503 Service Unavailable 


127 (Interworking, unspecified) 


504 Server timeout 


127 (Interworking, unspecified) 


505 Version not supported 


127 (Interworking, unspecified) 


513 Message too large 


127 (Interworking, unspecified) 


580 Precondition failure 


127 (Interworking, unspecified) 


OUU DUby CVciyWllulc 


^ 7 /I loQr Hii io\/\ 

1 / ^Ubui UUi>y) 


803 Decline 


21 (Call rejected) 


604 Does not exist anywhere 


1 (Unassigned (unallocated) number) 


606 Not acceptable 


127 (Interworking, unspecified) 
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NOTE: Alternative mappings are allowed per operator policy. 

5.3.9 Receipt of DISCONNECT 

If the MSC Server receives a DISCONNECT message from the UE prior to receiving a final response to the initial 
INVITE, the MSC Server shall send a CANCEL request. If a 200 OK response to the initial INVITE is received after 
sending the CANCEL request, the MSC Server shall send a BYE request to the IM CN subsystem to terminate the 

session. 

If the DISCONNECT message contains one or more cause information elements, the first cause information element 
shall be mapped to a Reason header field in the CANCEL or BYE request as follows: 

- set the protocol field to "Q.850"; and 

- set the protocol-cause field to the cause value field of the cause information element. 
NOTE: The inclusion of reason-text in the Reason header is implementation specific. 

5.4 Interworking of mobile terminating call setup from SIP to 
NAS signalling 

5.4.1 General 

The IM CN susbsystem terminating session shall be established in accordance with 3GPP TS 24.292 [7] and 3GPP TS 
24.229 [2]. The mobile terminating call shall be estabUshed at the visited MSC Server in accordance with 3GPP TS 
23.018 [8] and 3GPP TS 24.008 [3]. The following subclauses describe the additional requirements for interworking 
between SIP and NAS signalhng. 

5.4.2 Receipt of initial INVITE 

Upon receipt of an initial INVITE request, the MSC Server shall validate the INVITE request and SDP offer, if present, 
as described in 3GPP TS 24.292 [7]. 

After validating the INVITE request, the terminating party shall be validated as follows: 

- the MSC Server shall identify the terminating subscriber using the P-Called-Party-ID header or Request-URl 
from the INVITE request and use this to retrieve the VLR data; 

- if the VLR data cannot be retrieved, the MSC Server shall send a 500 Server Internal Error response to the 
INVITE request; 

- if the VLR data can be retrieved, the following checks shall be performed: 

- if the IMSI is detached, the MSC Server shall send a 500 Server Internal Error response to the INVITE 
request; 

NOTE 1: IMSl detached status could be the result of a race condition with CS domain access signalling which has 
not yet removed the IMS registration binding for this contact address. 

Upon successful validation of the terminating party, the MSC Server shall initiate the establishment of a MM 
connection as specified in 3GPP TS 24.008 [3]. If a MM connection cannot be established (e.g. no PAGE RESPONSE 
message is received), the MSC Server shall send a 408 Request Timeout response to the INVITE request. 

If the initial INVITE request includes a MIME body (part) according to subclause 4.4.1 of 3GPP TS 24.615 [44] with 
the "communication-waiting-indication" element contained in the "ims-cw" root element according to 
3GPP TS 24.615 [44J, and if the MSC Server determines that the incoming call can be presented to the subscriber as 
described in 3GPP TS 24.083 [26], then subclause 5.6.4.1 appUes. 

NOTE 2: Subclause 5.6.8.3.1.4 contains additional applicable procedures executed upon receipt of an initial 
INVITE request if the MSC Server is as conference participant. 
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5.4.3 Sending of SETUP 

After successful MM connection establishment, the MSC Server shall send a SETUP message as described in 3GPP TS 
24.008 |3] with the following INVITE request interworking applied: 

- The MSC Server may include a bearer capability 1 information element set to indicate teleservice 1 1 as 
described in 3GPP TS 22.003 [9]; 

- The MSC Server shall not include a bearer capabiUty 2 information element; 

- If a P-Asserted-Identity header containing a tel URI or a SIP URI with "user=phone" is present, the MSC Server 
shall use this header to build a calling party BCD number information element as follows: 

- if the tel URI or number within the SIP URI is in international format, set the type of number to 
"international number", otherwise set the type of number to "national number"; and 

- set the number plan identification to "ISDN/telephony numbering plan"; and 

- set the presentation indicator to "presentation allowed" ; and 

- set the screening indicator to "network provided"; and 

- set the number digits fields to the telephone number contained in the tel URI or SIP URI; 

NOTE 1: If the P-Asserted-Identity header contains both a tel URI and a SIP URI with "user=phone", the URI used 
for mapping is implementation specific. 

NOTE 2: The number mapping does not include any digits contained in the phone-context parameter. 

- If a P-Asserted-Identity header is present but does not contain a tel URI or a SIP URI with "user=phone", the 
following applies: 

- If a display name is present in the P-Asserted-Identity header, and if no Privacy header with priv-value set to 
"id" is present, and if the MSC Server supports the network option of mapping display name to calling name 
identity, the MSC Server may use the P-Asserted-Identity header to build a facility information element with 
a name indicator parameter set to the display name. 

NOTE 3: Interworking of display name received in conjunction with a tel URI or SIP URI to calUng name 

presentation using CNAP is subject to local regulatory requirements on calling Une identity and whether 
the originating network of the call is trusted to provide an authentic identity. 

- If no display name is present in any P-Asserted-Identity header, or if the MSC Server does not support the 
network option of mapping a display name to calling name identity, the MSC Server shall build a calUng 
party BCD number information element as follows: 

- set the type of number to "unknown" ; and 

- set the number plan identification to "unknown"; and 

- set the presentation indicator to "number not available due to interworking"; and 
set the screening indicator to "network provided"; and 

- do not include any number digits fields; 

If no P-Asserted-Identity header is present but a Privacy header with priv-value set to "id" is present, the MSC 
Server shall build a calling party BCD number information element as follows: 

set the type of number to "unknown"; and 

- set the number plan identification to "unknown"; and 

- set the presentation indicator to "presentation restricted" ; and 
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- set the screening indicator to "network provided"; and 

- do not include any number digits fields; 

If neither a P-Asserted-Identity header nor a Privacy header field with a priv-value set to "id" is present, then the 
MSC Server shall include no calhng party BCD number information element. 

If a P-Asserted-ldentity header containing a tel URl or a SIP URl with "user=phone" and a Privacy header with 
priv-value set to "id" are present, the MSC Server shall build a calling party BCD number information element 
as follows: 

set the type of number to "unknown"; and 

set the number plan identification to "unknown"; and 

- set the presentation indicator to "presentation restricted"; and 

- set the screening indicator to "network provided"; and 

- do not include any number digits fields. 

5.4.4 Receipt of CALL CONFIRMED 

Upon receipt of a CALL CONFIRMED message: 

if a bearer capabilities 1 information element is present and indicates a teleservice other than 11 as described in 
3GPP TS 22.003 [9], the MSC Server shall initiate call clearing procedures using a cause value of 58 (bearer 
capabiUty not presently available); 

- if a bearer capabilities 1 information element is present and includes a CTM text telephony indication set to 
"CTM text telephony is supported", the default behaviour of the MSC Server shall be to continue with caU setup 
but not to provide user plane interworking between CTM and RTP-text at the CS-MGW. 

NOTE: Conversion between CTM as described in 3GPP TS 26.226 [22] and RTP-text as described in 3GPP TS 
26.235 [21 J may be provided as an implementation option if the SDP offer included the payload type for 
RTP-text. Such conversion is outside the scope of the present document. 

5.4.5 Bearer establishment 

5.4.5.1 Network side bearer establishment 

If the initial INVITE request contained an SDP offer, the MSC Server should use the codecs received in the SDP offer 
and determine the codecs supported by the UE as specified in 3GPP TS 24.008 [3] to select and return a single codec in 
the SDP answer. 

The MSC Server shall reject all non-audio media descriptions from the SDP offer in the SDP answer. 
The SDP answer shall be returned in the first reliable response. 

If the initial INVITE request did not contain an SDP offer, the MSC Server should determine the codecs supported by 
the UE as specified in 3GPP TS 24.008 [3] and use this information when constructing a codec list for the SDP offer 
and send the SDP offer in the first reliable response to the INVITE request. 

5.4.5.2 Access bearer assignment 

The MSC Server shall initiate access bearer assigrmient only after the following conditions are satisfied: 

- the incoming side RTP cormection point has been successfully reserved and configured in the CS-MGW; and 

either: 

preconditions were not requested in the SDP of the initial INVITE request; or 

- an SDP offer has been received indicating that remote preconditions have been met. 
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For UTRAN and GERAN lu-mode, the NAS Synchronisation Indicator information element shall be used to inform the 
UE of the selected codec as specified in 3GPP TS 24.008 [3]. 

5.4.5.3 Transcoding 

The CS-MGW may include a speech transcoder based upon the speech coding information provided to each bearer 
termination. 

5.4.6 Receipt of ALERTING 

Upon receipt of the ALERTING message from the UE, the MSG Server shall send a 180 Ringing response. 

NOTE: Starting timer T301 (or a corresponding internal alerting supervision timing function) as specified in 

3GPP TS 24.008 [3] at the MSG Server is an implementation option. The default value for T301 in 3GPP 
TS 24.008 [3] is longer than the range specified for the IM GN subsystem's no reply timer specified in 
3GPP TS 24.604 [23], which should allow the IM GN subsystem to properly control GFNA. However, if 
T301 is started and expires prior to the no reply timer in the IM GN subsystem, the non-2xx response 
returned to the IM GN subsystem will prevent invocation of the GFNA service. 

5.4.7 Applying early media 

The MSG Server may instruct the GS-MGW to apply ringback tone or an announcement towards the IM GN subsystem 
in the following condition: 

- the MSG Server supports the P-Early-Media header as a network option; and 

- the P-Early-Media header was received in the initial INVITE request. 

If these conditions are met and the MSG Server chooses to apply early media, the following actions are taken: 

prior to applying an announcement, the MSG Server shall include in the 183 Session Progress response a P- 
Early-Media header authorizing backward early media; 

prior to applying ringback tone, the MSG Server shall include in the 180 Ringing response a P-Early-Media 
header authorizing backward early media. 

5.4.8 Call rejection or abandonment 

5.4.8.1 Receipt of RELEASE COMPLETE or DISCONNECT 

If the MSG Server receives a RELEASE GOMPLETE or DISGONNEGT message from the UE during call 
estabhshment, the MSG Server shall send a status-code 4xx or 5xx response to the initial INVITE. The status-code sent 
shall be determined by examining the first cause information element received in the RELEASE GOMPLETE or 
DISGONNEGT message and applying the mapping specified in table 5.4.8.1.1. 

Table 5.4.8.1.1 : Mapping the cause information element to the 4xx/5xx/6xx status-code 



Cause value 


SIP status-code 


1 (Unassigned (unallocated) number 


404 Not Found 


3 (No route to destination) 


500 Server Internal Error 


6 (Channel unacceptable) 


500 Server Internal Error 


8 (Operator determined barring) 


480 Temporarily Unavailable 


16 (Normal call clearing) 


480 Temporarily Unavailable 


17 (User busy) 


486 Busy Here 


1 8 (No user responding) 


480 Temporarily Unavailable 
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Cause value 


SIP status-code 


19 (User alerting, no answer) 


480 Temporarily Unavailable 


(uaii rejecteo) 


480 Temporarily Unavailable 


22 (Number changed) 


41 u vjone 


25 fPre-erriDtion^ 


480 Temoorarilv Unavailable 

~w w 1 w III l^w 1 CiLI 1 1 y 1 1 U V Ul lUI^ 1 w 


26 fNon selected user clearina^ 


480 Temoorarilv Unavailable 

^T^\J 1 ^ III WW 1 CiLI 1 1 y 1 1 U V Ul lUI^ 1 w 


27 ^Destination out of orders 

# \ L^^OLI 1 1 ULI V 1 1 \-M L w 1 w 1 WW 1 / 


502 Bad Gatewav 


28 (Invalid number format (incomplete 
number) 


484 Address Incomplete 


29 (Facility rejected) 


500 Server Internal Error 


oU (riesponse to o l a l Uo tNUUIHY) 


500 Server Internal Error 


31 (Normal, unspeciflGd) 


480 Temporarily Unavailable 


34 (No circuit/channel available) 


480 Temporarily Unavailable 


38 (Network out of order) 


500 Server Internal Error 


41 (Tpmnorarv failurp^ 

~ 1 \ 1 w 1 1 1 V 1 tnil y 1 C41 1 1 w / 


500 Server Internal Error 


42 fSwitchinn pnuinmpnt nonnp<?tinn^ 

I V V 1 IV/I III 1 ^ w 1 K/l 1 1 w 1 1 L \J\J 1 1 u w 11 w 1 1 1 


500 Server Internal Error 


43 ^Acnp*?^ information di<?nardpd^ 

~w yfiwwwww 1 1 1 1 \J 1 1 1 1 Ull w 1 1 \^ 1 OwUI / 


500 Server Internal Error 


44 fReauested circuit/channel not 

~~ \ 1 i wU U w w LwW Wll WUIl/wl lUI 1 1 1 wl 1 1 \J I 

available) 


500 Server Internal Error 


47 (Resources unavailable, unspecified) 


500 Server Internal Error 


49 (Quality of service unavailable) 


500 Server Internal Error 


50 ^Reouested facilitv not subscribed^ 

WW y 1 i WW U w w Iww 1 Uwl 1 1 L y 1 1 w L wU WW wl 1 www / 


500 Server Internal Error 


55 (Incoming calls barred within the CUG) 


480 Temporarily Unavailable 


57 (Bearer capability not authorized) 


500 Server Internal Error 


58 (Bearer capability not presently 
available) 


500 Server Internal Error 


63 ^Service or ootion not available 

WW \ w 1 V 1 w^ \J 1 wln^ LI w 1 1 1 1 w L U V KtLI tKXK/ 1 w j 

unspecified) 


500 Server Internal Error 


65 fBparpr <^prvir;p not imolpmpntpd^ 

\J\J \ w C^l w 1 O w 1 V 1 w w II \J L till K/i wl 1 Iwl ILwwf 


500 Server Internal Error 


68 (ACM equal to or greater than ACMmax) 


500 Server Internal Error 


69 (Requested facility not implemented) 


500 Server Internal Error 


70 (Only restricted digital information 
bearer capability is available) 


500 Server Internal Error 


79 ^Service or oration not imnlemented 

f w \ w 1 V 1 WW w 1 w LI w II 1 1 w L 1 1 1 1 wl wl 1 1 w 1 1 Lww J 

unspecified) 


500 Server Internal Error 


81 (Invalid transaction identifier value) 


500 Server Internal Error 


of (User not memoer ot uuti) 


480 Temporarily Unavailable 


88 (Incompatible destination) 


500 Server Internal Error 


91 (Invalid transit network selection) 


404 Not Found 


95 (Semantically incorrect message) 


500 Server Internal Error 


96 (Invalid mandatory information) 


500 Server Internal Error 


97 (Message type non-existent or not 
implemented) 


500 Server Internal Error 
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Cause value 


SIP status-code 


98 (Message type not compatible with 
protocol state) 


500 Server Internal Error 


99 (Information element non-existent or not 
implemented) 


500 Server Internal Error 


100 ^Conditional IE errors 


500 Server Internal Error 


101 (Message not compatible with protocol 

state) 


500 Server Internal Error 


102 (Recovery on timer expiry) 


480 Temporarily Unavailable 


1 1 1 (Protocol error, unspecified) 


500 Server Internal Error 


127 (Interworking, unspecified) 


480 Temporarily Unavailable 



NOTE 1: Alternative mappings are allowed per operator policy. 

The first cause information element included in the RELEASE COMPLETE or DISCONNECT message shall be 
mapped to a Reason header field in the SIP final response sent as a result of this clause as follows: 

- set the protocol field to "Q.850"; and 

- set the protocol-cause field to the cause value field of the cause information element. 
NOTE 2: The inclusion of reason-text in the Reason header is implementation specific. 

5.4.8.2 Receipt of CANCEL or BYE 

If the MSC Server receives a CANCEL or BYE request, the MSC Server shall initiate call clearing procedures by 
sending a DISCONNECT message towards the UE as described in 3GPP TS 24.008 [3] with the following interworking 
appUed: 

- If one or more Reason headers is included in the CANCEL or BYE request, then the cause value of each Reason 
header shall be mapped to a cause information element in the DISCONNECT message as follows: 

if the Reason header contains a Q.850 cause value or a SIP status-code, the cause information element shall 
be built as described in subclause 5.3.8. 

- if no Reason header is included in the CANCEL or BYE request, a cause value set to 3 1 (normal, unspecified) , 
coding standard set to 'Standard defined for the GSM PLMNs' and location set to "network beyond interworking 
point" shall be used in the cause information element in the DISCONNECT message. 

5.4.9 Receipt of CONNECT 

Upon receipt of the CONNECT message from the UE, the MSC Server shall send a 200 OK response to the initial 
INVITE. 

Interworking applied for the TIR services is described in subclause 5.6.2.2. 

5.4.10 Call failure procedures 

The MSC Server shall handle call failures (e.g. timer expiration) during mobile terminating call establishment in 
accordance with 3GPP TS 24.008 [3]. The cause value used towards the calling user as specified in 3GPP TS 24.008 [3] 
shall be mapped to a final response to the INVITE request as specified in subclause 5.4.8.1. 
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5.5 Interworking of established call clearing between NAS 
signalling and SIP 

5.5.1 General 

The following subclauses define the procedure and signalling interworking performed by the MSC Server for call 
clearing of an established call. This interworking is independent of the direction of original call establishment. 

Call clearing during call setup is described in subclauses 5.3.7, 5.3.8, 5.3.9, 5.4.8.1 and 5.4.10. 

5.5.2 Clearing initiated by the mobile 

MSC Server handling of call clearing initiated by the mobile shall be in accordance with 3GPP TS 24.008 [3] with the 
additional interworking defined here. 

Upon receipt of a DISCONNECT message, the MSC Server shall send a BYE request to the IM CN subsystem. The 
cause information element in the DISCONNECT message shall be mapped to a Reason header in the BYE request 
according to in subclause 5.4.8.1. 

5.5.3 Clearing initiated by the IM CN subsystem 

Upon receipt of a BYE request, the MSC Server shall send a DISCONNECT message towards the mobile. If one or 
more Reason header fields is included in the BYE request, each Reason header field shall be mapped to a cause 
information element in the DISCONNECT message according to subclause 5.3.8. 

If no Reason header is present, a cause information element value of 16 (Normal call clearing) shall be used. 

5.5.4 Autonomous clearing initiated by the MSC Server 

If the MSC Server determines due to internal procedures that the call shall be released, call release shall be in 
accordance with 3GPP TS 24.008 [3] with the additional interworking defined here. 

The MSC Server shall send a BYE request to the IM CN subsystem. The MSC Server shall ahgn the value used in the 
cause information element in the DISCONNECT message with the value used in the Q.850 protocol-cause field in the 
Reason header of the BYE request. 

5.6 Supplementary Services invocation 

5.6.1 Originating identification presentation/restriction (OIP/OIR) 

The interworking required for OIP is defined in subclause 5.4.3. 
The interworking required for OIR is defined in subclause 5.3.3.2. 

5.6.2 Terminating identification presentation/restriction (TIP/TIR) 
5.6.2.1 Terminating identification presentation (TIP) 

When interworking a SIP 200 OK (INVITE) response to a CONNECT message as described in subclause 5.3.6, a MSC 
Server which supports the normal operation of the connected number supplementary service as described in 3GPP TS 
24.081 [12] shall apply the following interworking for the TIP supplementary service: 

if a P-Asserted-ldentity header containing a tel URl or a SIP URl with "user=phone" is present, the MSC Server 
shall use this header to build a connected number information element as follows: 

- if the tel URl or number within the userinfo part of the SIP URl is in international format, set the type of 
number to "international number", otherwise set the type of number to "national number"; and 
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- set the number plan identification to "ISDN/telephony numbering plan"; and 

- set the presentation indicator to "presentation allowed" ; and 

- set the screening indicator to "network provided"; and 

- set the number digits fields to the telephone number contained in the tel URI or the userinfo part of the SIP 
URI;or 

NOTE 1: If the P-Asserted-Identity header contains both a tel URI and a SIP URI with "user=phone", the URI used 
for mapping is implementation specific. 

NOTE 2: The number mapping does not include any digits contained in the phone-context parameter. 

if a P-Asserted-ldentity header is present but does not contain a tel URI or a SIP URI with "user=phone", the 
MSC Server shall build a connected number information element as follows: 

- set the type of number to "unknown" ; and 

- set the number plan identification to "unknown"; and 

- set the presentation indicator to "number not available due to interworking"; and 

- set the screening indicator to "network provided"; and 

- do not include any number digits fields; or 

- if no P-Asserted-ldentity header is present but a Privacy header with priv-value set to "id" is present, the MSC 
Server shall build a connected number information element as follows: 

- set the type of number to "unknown" ; and 

- set the number plan identification to "unknown"; and 

set the presentation indicator to "presentation restricted"; and 

- set the screening indicator to "network provided"; and 

- do not include any number digits fields; or 

if neither a P-Asserted-ldentity header nor a Privacy header field with a priv-value set to "id" is present, then no 
connected number information element shall be included. 

5.6.2.2 Terminating identification restriction (TIR) 

The MSC Server shall not include a Privacy header in any response to an INVITE request. 

NOTE: 3GPP TS 24.081 [12] does not provide a mechanism for a terminator to temporarily override default 

settings for this service. The inclusion of a Privacy header could lead to the AS serving the terminating 
user to mistakenly assume that a default setting is being temporarily overridden by the terminating user. 
Omitting the Privacy header allows the AS supporting the terminating user to perform the appropriate 
actions for the TIR service in "permanent mode" as specified in 3GPP TS 24.608 [14]. 

5.6.3 Communication Hold (HOLD) 
5.6.3.1 HOLD initiated via NAS signalling 
5.6.3.1.1 Hold 

When the MSC Server receives a HOLD message as specified in 3GPP TS 24.083 [26] and the media on the IM CN 
subsystem side of the CS-MGW is "sendonly" or "inactive", no interworking is required and the MSC Server shall send 
a HOLD ACKNOWLEDGE message to the UE as specified in 3GPP TS 24.083 [26]. If the media on the IM CN 
subsystem side is "recvonly" or "sendrecv", the MSC Server shall send an UPDATE or re-INVITE request containing 
an SDP offer configured as follows: 
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- mark the media as "sendonly" or "inactive" as described in 3GPP TS 24.610 [27]; and 

if RTCP is disabled for this media stream, include RR and RS bandwidth modifiers with values greater than zero 
to enable RTCP as described in 3GPP TS 26.114 [28] subclause 7.3.1. 

Upon receipt of the SDP answer in a 200 OK response to the UPDATE or re-INVITE request, the MSG Server shall 
send a HOLD AGKNOWLEDGE message to the UE as specified in 3GPP TS 24.083 [26]. 

If the SDP offer is rejected or a non-200 response is received to the UPDATE or re- INVITE request, the MSG Server 
shall send a HOLD REJEGT message to the UE as specified in 3GPP TS 24.083 [26] with cause parameter set to 
"Facility rejected". 

5.6.3.1.2 Resume 

When the MSG Server receives a RETRIEVE message as specified in 3GPP TS 24.083 [26] and the media on the IM 
GN subsystem side of the GS-MGW is "recvonly" or "sendrecv", no interworking is required and the MSG Server shall 
send a RETRIEVE AGKNOWLEDGE message to the UE as specified in 3GPP TS 24.083 [26]. If the media on the IM 
GN subsystem side is "sendonly" or "inactive", the MSG Server shall send an UPDATE or re-lNVlTE request 
containing an SDP offer with media marked as "recvonly" or "sendrecv" as described in 3GPP TS 24.610 [27]. The 
MSG Server may include RR and RS bandwidth modifiers set to zero in the SDP offer to disable RTGP. 

Upon receipt of the SDP answer in a 200 OK response to the UPDATE or re-lNVlTE request, the MSG Server shall 
send a RETRIEVE AGKNOWLEDGE message to the UE as specified in 3GPP TS 24.083 [26]. 

If the SDP offer is rejected or a non-200 response is received to the UPDATE or re-INVlTE request, the MSG Server 
shall send a RETRIEVE REJEGT message to the UE as specified in 3GPP TS 24.083 [26] with cause parameter set to 
"Facility rejected". 

5.6.3.2 HOLD initiated via SIP signalling 

5.6.3.2.1 Hold 

The IM GN subsystem makes a hold request by sending an UPDATE or re-INVITE request with an "inactive" or 
"sendonly" SDP attribute, depending on the current state of the session. Upon receipt of a hold request from the IM GN 
subsystem, the MSG Server shall perform the following interworking: 

- if the MSG Server received a non-zero SS screening indicator as defined in 3GPP TS 24.080 [29] from the UE, 
the MSG Server shall send a FACILITY message indicating the call has been placed on hold as specified in 
3GPPTS 24.083 [26]; 

if the MSG Server did not receive a non-zero SS screening indicator from the UE, the MSG Server shall not send 
any message to the UE. 

5.6.3.2.2 Resume 

The IM GN subsystem requests to resume a session by sending an UPDATE or re-INVITE request with an "recvonly" 
or "sendrecv" SDP attribute, depending on the current state of the session. Upon receipt of a resume request from the 
IM GN subsystem, the MSG Server shall perform the following interworking: 

- if the MSG Server received a non-zero SS screening indicator as defined in 3GPP TS 24.080 [29] from the UE, 
the MSG Server shall send a FAGILITY message indicating the call has been retrieved as specified in 3GPP TS 
24.083 [26]; 

- if the MSG Server did not receive a non-zero SS screening indicator from the UE, the MSG Server shall not send 
any message to the UE. 

5.6.4 Communication Waiting (CW) 
5.6.4.1 Receipt of initial INVITE 

NOTE: Subclause 5.4.2 contains general apphcable procedures executed upon receipt of an initial INVITE 
request. 
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If the initial INVITE request includes: 

a MIME body (part) according to subclause 4.4.1 of 3GPP TS 24.615 [44] with the "communication-waiting- 
indication" element contained in the "ims-cw" root element according to 3GPP TS 24.615 [44]; or 

- does not contain a Replaces header field corresponding to a established dialog and the target of the INVITE 
request is engaged in the established SIP dialog; 

then, upon interworking the initial INVITE request to a SETUP message as described in subclause 5.4.3, the MSG 
Server shall apply the following additional interworking: 

- the MSG Server shall include a Signal information element with value 7 (call waiting tone on); and 

- if the INVITE request includes a MIME body (part) according to subclause 4.4. 1 of 3GPP TS 24.615 [44] with 
the "communication-waiting-indication" element contained in the "ims-cw" root element according to 
3GPPTS 24.615 [44]: 

- the MSG Server shall store an indication that this session includes a GW AS; and 

the MSG Server may start timer TUE-GW as described in 3GPP TS 24.615 [44]. 

If the GALL GONFIRMED message received by the MSG Server during mobile terminating call setup contains a Gause 
information element set to a value of 17 (User busy), then upon interworking the subsequent ALERTING message to a 
180 Ringing response as described in subclause 5.4.6, the MSG Server shall apply the following additional 
interworking: 

- the MSG Server shall insert an Alert-Info header set to "um:alert:service:call-waiting" as described in 
3GPP TS 24.615 [44] into the 180 Ringing response. 



If the subscriber chooses to accept the waiting call and put the existing call on hold, the MSG Server shall: 

- upon receipt of the HOLD message for the existing call, apply the interworking specified in subclause 5 .6.3 . 1 . 1 ; 
and 

- upon receipt of the GONNEGT message for the waiting call, stop timer Tue-cw if it was started and apply the 
interworking specified in subclause 5.4.9. 

If the subscriber chooses to accept the waiting call and release the existing call, the MSG Server shall: 

- upon receipt of the DISGONNEGT message for the existing call, apply the interworking specified in subclause 
5.5.2; and 

- upon receipt of the GONNEGT message for the waiting call, stop timer Tue-cw if it was started and apply the 
interworking specified in subclause 5.4.9. 



If the MSG Server receives a first clearing message from the UE during call establishment, the cause value used 
towards the calling user as specified in 3GPP TS 24.008 [3] shall be mapped to a final response to the INVITE request 
as specified in subclause 5.4.8.1, except for cause codes: 

19 (User alerting, no answer) and 18 (No user responding). A first clearing message from the UE during call 
establishment with cause code 19 (User alerting, no answer) or 18 (No user responding) shall be mapped to the 
480 (Temporarily unavailable) final response including a Reason header field (see RFG 3326 [45]) with the 
protocol set to "Q.850" and the cause set to "19" or "18", respectively; 

- 63 (Service or option not available, unspecified) and 69 (Requested facility not implemented): 

- if the MSG Server stored an indication that the session includes a GW AS, a first clearing message from the 
UE during call establishment with cause code 63 (Service or option not available, unspecified) or 69 
(Requested facility not implemented) used towards the calling user as specified in 3GPP TS 24.008 [3] shall 
be mapped to the 415 (Unsupported Media Type) final response; or 



5.6.4.2 



Accepting the waiting call 



5.6.4.3 



Rejecting the waiting call 
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if the MSC Server did not store an indication that the session includes a CW AS, the cause codes 63 (Service 
or option not available, unspecified) and 69 (Requested facility not implemented) used towards the calling 
user as specified in 3GPP TS 24.008 [3] shall be mapped to a final response to the ESTVITE request as 
specified in subclause 5.4.8.1. 

The MSC Server shall stop timer Tue-cw if it was started. 

5.6.4.4 Communication release during waiting condition 

Upon receipt of a BYE or CANCEL request for the waiting call, the MSC Server shall stop timer Tue-cw if it was 
started, and: 

- if the BYE or CANCEL request includes a Reason header field (see RFC 3326 [45]) with the protocol set to 
"SIP" and the cause set to "408" then the MSC Server shall send a first clearing message according to subclause 
5.4.8.2, with the following addition: 

- the Cause information element shall be set to cause 102 "recovery on timer expiry"; or 

- the MSC Server shall act in accordance with subclause 5.4.8.2. 

5.6.4.5 CW condition timeout 

If timer Tue-cw was started and expires, the MSC Server shall: 

- send a DISCONNECT message as described in 3GPP TS 24.008 [3], towards the UE for the waiting call, 
including the Cause information element, where the cause values is set to 102 "recovery on timer expiry", the 
coding standard set to "Standard defined for the GSM PLMNs" and location set to "network beyond 
interworking point"; 

if the MSC Server stored an indication that the session includes a CW AS, send a 480 (Temporarily unavailable) 
final response, including a Reason header field set to cause 19, according to 3GPP TS 24.615 [44] in response to 
the initial INVITE request; 

- if the MSC Server did not store an indication that the session includes a CW AS, the MSC Server shall act in 
accordance with subclause 5.4.10. 

NOTE: Starting timer T2 or (optionally) T3 (or corresponding internal alerting supervision timing functions) as 
specified in 3GPP TS 24.083 [26] is an implementation option. Corresponding timers have been defined 
in 3GPP TS 24.615 [44] and 3GPP TS 24.604 [23]. If timers T2 or optionally T3 are started and expire, 
any resulting SIP responses that are not a 480 (Temporarily unavailable) final response, including a 
Reason header field set to cause 19, can interact with CW and (optionally) CDIV. 

5.6.4.6 Notification to originator 

For originating calls interworked to the IM CN subsystem as described in subclause 5.3, if the MSC Server receives a 
180 Ringing response with a Alert-Info header field set to "urn:alert:service:call-waiting" according to 
3GPP TS 24.615 [44], the MSC Server shall, according to 3GPP TS 24.083 [26], send if possible, the ALERTING 
message as the carrier message for the Call Waiting notification. Otherwise the MSC Server shall send a FACILITY 
message as the carrier message for the Call Waiting notification as specified in 3GPP TS 24.083 [26]. 

5.6.5 Communication Barring (CB) 

When interworking a 4xx, 5xx or 6xx response to the initial INVITE request to a DISCONNECT message as described 
in subclause 5.3.8, the MSC Server shall apply the following additional interworking for the CB services described in 
3GPPTS 24.611 [31]: 

- if a 433 Anonymity Disallowed response is received, the MSC Server shall include in the DISCONNECT a 

NotifySS operation containing an SS-Code set to the common code for incoming barring services and an SS- 
Status set to indicate the service is active and operative as specified in 3GPP TS 24.088 [30]; 
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if a 603 Decline response is received, the MSC Server shall include in the DISCONNECT a NotifySS operation 
containing an SS-Code set to the common code for all barring services and an SS-Status set to indicate the 
service is active and operative as specified in 3GPP TS 24.088 [30]. 

NOTE: The common SS code is used as 3GPP TS 24.61 1 [3 1] specifies the use of a 603 Decline response for 
both the OCB and ICB services. 

5.6.6 Communication Diversion 

5.6.6.1 General 

The following subclauses describe the MSC Server interworking behaviour related to the Communication Diversion 
(CDIV) services defined in 3GPP TS 24.604 [23]. 

5.6.6.2 CDIV invocation 

5.6.6.2.1 Communication Forwarding Unconditional (CFU) 

Invocation of CFU is handled by the IM CN subsystem as described in 3GPP TS 24.604 [23] and requires no 
interworking at the MSC Server. 

5.6.6.2.2 Communication Fonwarding Busy (CFB) 

For network determined user busy, invocation of CFB is handled by the IM CN subsystem as described in 3GPP TS 
24.604 [23] and requires interworking at the MSC Server. 

For user determined user busy during mobile terminating call establishment as described in subclause 5.4, if the MSC 
Server receives a DISCONNECT, RELEASE or RELEASE COMPLETE message from the UE with a cause 
information element set to "User Busy", the MSC Server shall perform the interworking described in subclause 5.4.8.1. 

5.6.6.2.3 Communication Forwarding No Reply (CFNR) 

Invocation of CFNR is handled by the IM CN subsystem as described in 3GPP TS 24.604 [23] and requires no 
interworking at the MSC Server. 

5.6.6.2.4 Communication Fonwarding on Not Logged-ln (CFNL) 

Invocation of CFNL is handled by the IM CN subsystem as described in 3GPP TS 24.604 [23] and requires no 
interworking at the MSC Server. 

5.6.6.2.5 Communication Deflection (CD) 

During mobile terminating call establishment as described in subclause 5.4, if the MSC Server receives a 
DISCONNECT message from the UE with a facility information element containing a call deflection request as 
specified in 3GPP TS 24.072 [25], the MSC Server shall send a 302 Moved Temporarily response to the initial INVITE 
with the following interworking applied: 

the DeflectedToNumber parameter in the facility information element received in the DISCONNECT message is 
used to derive a Contact header as follows: 

if the nature of address indicator is set to "international number", then the address digits in the 
DeflectedToNumber parameter, prefixed with a "+", shall be used to build a tel URI or a SIP URI with 
"user=phone"; or 

- if the nature of address indicator is not set to "international number", then the MSC Server shall either: 

- convert the address digits in the DeflectedToNumber parameter to international format by prefixing the 
number digits with "+CC" and use this to build a tel URI or a SIP URI with "user=phone"; or 

NOTE 1 : CC is the country code of the network in which the MSC Server is located. 
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- use the address digits in the DeflectedToNumber parameter to build a tel URI or a SIP URI with 

"user=phone". The phone-context parameter shall include the home network domain name defined for 
IMS centralized services in 3GPP TS 23.003 [10]. For geo-local numbers, the home domain name shall 
be prefixed by the "geo-local" string according to 3GPP TS 24.229 [2]. 

NOTE 2: The manner in which the MSG Server distinguishes between geo-local and home-local numbers is 
implementation specific. 

5.6.6.2.6 Communication Forwarding on Subscriber Not Reacliable (CFNRc) 

Subclause 5.4.2 describes a number of scenarios where the MSG Server determines the terminating user is not reachable 
prior to sending the SETUP message and returns the appropriate response to the INVITE request to allow GFNRc to be 
initiated in the IM GN subsystem. If the MSG Server determines the terminating user is not reachable prior to sending 
the SETUP message for any other scenario not described in subclause 5.4.2, the MSG Server shall send a 500 Server 
Internal Error response to the initial INVITE request. 

5.6.6.3 Notifications relating to CDIV 

5.6.6.3.1 Communication Diversion Notification (CDIVN) 

The default behaviour at the MSG Server is not to issue a subscription for GDIVN. 

NOTE: The MSG Server may decide for example to subscribe to GDIVN as specified in 3GPP TS 24.604 [23] as 
an operator option, but such interworking is outside the scope of the present document. 

5.6.6.3.2 Notification to an originating user on CS access 

For originating calls interworked to the IM CN subsystem as described in subclause 5.3, if communication diversion 
occurs for a served user with the subscription option "Originating user receives notification that his communication has 
been diverted (forwarded or deflected)" as described in 3GPP TS 24.604 [23], the following interworking shall be 
applied upon receipt of a 181 Gall Is Being Forwarded response: 

- if a History-Info header is present and the next to last history entry contains a "cause" parameter set to a value 
Usted in table 5.6.6.3.2.1, the MSG Server shall send a FAGILITY message containing a NotifySS operation 
indicating the call has been forwarded. The NotifySS operation shall contain an SS-Gode as specified in 3GPP 
TS 24.082 [24] and 3GPP TS 24.072 [25] mapped from the value of the "cause" parameter according to table 
5.6.6.3.2.1; 



Table 5.6.6.3.2.1 : Mapping the History-Info cause value to SS-Code 



Cause value 


SS-Code 


302 


CFU 


404 


Common SS-Code for all forwarding SS 


408 


CFNRy 


480 


CD 


486 


CFB 


487 


CD 


503 


CFNRc 



NOTE: Per 3GPP TS 24.604 [23] the History-Info header can also be received in a 180 Ringing or 200 OK 
response to the initial INVITE request. No interworking is performed in these scenarios as 3GPP TS 
24.082 [24] does not allow this information to be presented to the subscriber in a manner consistent with 
3GPPTS 24.604 [23]. 
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5.6.6.3.3 Notification to a terminating user on CS access 

When interworking a SIP INVITE request to a SETUP message as described in subclause 5.4.3, the MSC Server shall 
apply the following interworking to provide notification of CDIV if a History-Info header is present in the INVITE 
request: 

if the next to last history entry in the History-Info header contains a "cause" parameter set to a value listed in 
table 5.6.6.3.2.1, the MSC Server shall send a FACILITY information element containing a NotifySS operation 
indicating the call has been forwarded. The NotifySS operation shall contain an SS-Code as specified in 3GPP 
TS 24.082 [24] and 3GPP TS 24.072 [25] mapped from the value of the "cause" parameter according to table 
5.6.6.3.2.1. 

- if the next to last history entry in the History-Info header does not contain an escaped privacy header with a 
value of "history", then the following additional interworking shall be applied: 

if the hi-targeted-to-uri contains a tel URI or a SIP URI with "user=phone", the MSC Server shall include a 
redirecting party BCD number information element set as follows: 

- if the tel URI or telephone number within the SIP URI is in international format, set the type of number 
to "international number", otherwise set the type of number to "national number"; and 

set the number plan identification to "ISDN/telephony numbering plan"; and 

set the presentation indicator to "presentation allowed"; and 

- set the screening indicator to "network provided"; and 

- set the number digits fields to the telephone number contained in the tel URI or SIP URI; 

NOTE: The number mapping does not include any digits contained in the phone-context parameter. 

- otherwise, the MSC Server shall use the hi-targeted-to-uri to build a redirecting party BCD number 
information element as follows: 

- set the type of number to "unknown" ; and 

- set the number plan identification to "unknown"; and 

- set the presentation indicator to "number not available due to interworking"; and 

- set the screening indicator to "network provided" . 

5.6.7 Explicit Communication Transfer (ECT) 

5.6.7.1 General 

The following subclauses describe the MSC Server interworking behaviour related to the ECT service defined in 3GPP 
TS 24.629 [33] and a UE using CS access domain signalling specified in 3GPP TS 24.091 [32]. 

5.6.7.2 MSC Server as transferor on behalf of UE 

When the MSC Server receives a FACILITY message containing an ECT request from a UE with one answered call in 
a held state and another call in an answered and active or alerting state as specified in 3GPP TS 24.091 [32], the MSC 
Server shall build and send a REFER request as specified for a transferor UE in 3GPP TS 24.629 [33]. 

When the MSC Server receives a NOTIFY request on the REFER dialog, interworking shall be apphed based upon the 
SIP response status-code contained in the "message/sipfrag" message body as follows: 

if status-code 100 Trying is received, no interworking is applied; 

- if status-code 200 OK is received, the MSC Server shall send a FACILITY message indicating transfer success 
to the UE as specified in 3GPP TS 24.091 [32]. The MSC Server shall then initiate clearing of the two calls 
towards the UE as specified in 3GPP TS 24.091 [32] and initiate clearing of the IM CN subsystem session with 
the transferee as specified in subclause 5.5.4. 
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if status-code 503 is received, the MSC Server shall send a FACILITY message with a return error parameter set 
to "SystemFailure" and leave the two calls from the UE in the conditions they were in prior to the ECT request; 

- if any other status-code is received, the MSC Server shall send a FACILITY message with a return error 
parameter set to "IllegalSS-Operation" and leave the two calls from the UE in the conditions they were in prior 
to the ECT request. 

5.6.7.3 MSC Server as transferee on behalf of UE 

5.6.7.3.1 Actions without 3PCC 

NOTE 1: CS domain access signalling as specified in 3GPP TS 24.091 [32] does not provide a mechanism to 

present the transfer request to the transferee for authorization of the transfer. Automatic acceptance and 
execution of the REFER request by the MSC Server can therefore pose a security risk or have unwanted 
charging consequences. Acceptance of REFER requests is therefore subject to operator policy, which is 
outside the scope of the present document. 

When the MSC Server receives a REFER request in the context of a call transfer scenario as described in 3GPP TS 
24.629 [33] subclause 4.5.2.4.1.2.2, the MSC Server may perform the actions specified for a transferee UE in 3GPP TS 
24.629 [33]. 

If the MSC Server does not support accepting REFER requests on behalf of the UE per operator policy, then the MSC 
Server shall return a 403 Forbidden response. 

If the MSC Server received a non-zero SS screening indicator from the UE as defined in 3GPP TS 24.080 [29], then 
upon sending the NOTIFY request indicating that the transfer is complete, the MSC Server may send a FACILITY 
message to the UE as specified in 3GPP TS 24.091 [32]. The MSC Server may include an Rdn parameter set to indicate 
that the remote party number is not available due to interworking. 

NOTE 2: The remote party number, as indicated in the Refer-To header sent by the transferor, is not available to 
the MSC Server as it is replaced by the transferor AS as specified in 3GPP 24.629 [33]. 

NOTE 3: Depending on the conferencing implementation in the IM CN subsystem (e.g. the manner in which users 
are invited to a conference), the MSC Server might not be able to distinguish between REFER requests 
for the ECT service and REFER requests for the conferencing service. In such cases, the MSC Server will 
not know which SS operation to indicate in the FACILITY message. Handling of this scenario is 
implementation specific. 

5.6.7.3.2 Actions with 3PCC 

When 3PCC is used for ECT as specified in 3GPP TS 24.629 [33], no special interworking is required at the MSC 
Server. 

5.6.7.4 MSC Server as transfer target on behalf of UE 

When the MSC Server receives an INVITE request which does not replace an existing session (e.g. blind ECT), the 
MSC Server shall follow the interworking procedures specified in subclause 5.4. 

When the MSC Server receives an INVITE request which replaces an existing session, the MSC Server shall perform 
the actions specified for a transfer target UE in 3GPP TS 24.629 [33]. If the MSC Server received a non-zero SS 
screening indicator as defined in 3GPP TS 24.080 [29], then upon successful session establishment with the transferee 
the MSC Server shall send a FACILITY message to the UE as specified in 3GPP TS 24.091 [32] with the following 
interworking applied: 

if a Privacy header with priv-value set to "id" is present, the MSC Server may include an Rdn parameter in the 
FACILITY message set to indicate presentation restricted as specified in 3GPP TS 24.080 [29]; 

- if a Privacy header with a priv-value set to "id" is not present in the INVITE request, then: 

if a P-Asserted-Identity header containing a tel URI or a SIP URI with "user=phone" is present in the 
INVITE, the MSC Server may include an Rdn parameter in the FACILITY message with a value set to the 
telephone number contained in this URI; 
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if a P-Asserted-Identity header is present but does not contain a tel URI or a SIP URI with "user=phone", the 
MSC Server may include an Rdn parameter in the FACILITY message set to indicate the number is not 
available due to interworking as specified in 3GPP TS 24.080 [29]. 

5.6.8 Conference (CONF) 

5.6.8.1 General 

IM CN subsystem CONF functionality at a MSC Server is specified in 3GPP TS 24.292 [7]. The following subclauses 
describe the MSC Server interworking behaviour related to the CONF service defined in 3GPP TS 24.605 [35] and a 
UE using CS access domain signalling specified in 3GPP TS 24.084 [34]. 

5.6.8.2 MSC Server as conference creator 

5.6.8.2.1 Conference creation 

When the MSC Server receives a BuildMPTY request from a UE with one active call and one held call as described in 
3GPP TS 24.084 [34], the MSC Server shall initiate conference creation and invite the remote parties to the conference 

as described in 3GPP TS 24.292 [7]. 

NOTE: Conference creation and inviting users to the conference are two distinct actions in the IM CN subsystem. 
However, in CS access signalling a single message creates the conference and adds the existing calls to 
the conference. 

After receiving NOTIFY requests indicating both remote parties have successfully transferred to the conference, the 
MSC Server shall send a FACILITY message indicating BuildMPTY success as specified in 3GPP 24.084 [34]. 

If a non-200 response to the INVITE request which attempts to create the conference is received, the MSC Server shall 
send a FACILITY message with a retum error parameter set to "SystemFailure" and leave the two calls from the UE in 
the conditions they were in prior to the ECT request. 

5.6.8.2.2 Putting the conference on ho\d 

When the MSC Server receives a HoldMPTY request from a UE with an active conference, the MSC Server shall send 
an UPDATE or re-INVITE request containing a new SDP offer as described in subclause 5.6.3.1.1. 

Upon receipt of the SDP answer in a 200 OK response to the UPDATE or re-INVITE request, the MSC Server shall 
send a FACILITY message indicating success as specified in 3GPP TS 24.084 [34]. 

If the SDP offer is rejected or a non-200 response is received to the UPDATE or re-INVITE request, the MSC Server 
shall send a FACILITY message as specified in 3GPP TS 24.084 [34] with a retum error parameter set to 
"SystemFailiu^e". 

5.6.8.2.3 Resuming a lield conference 

When the MSC Server receives a RetrieveMPTY request from a UE with a conference on hold, the MSC Server shall 
send an UPDATE or re-INVITE request containing a new SDP offer as described in subclause 5.6.3.1.2. 

Upon receipt of the SDP answer in a 200 OK response to the UPDATE or re-INVITE request, the MSC Server shall 
send a FACILITY message indicating success as specified in 3GPP TS 24.084 [34]. 

If the SDP offer is rejected or a non-200 response is received to the UPDATE or re-INVITE request, the MSC Server 
shall send a FACILITY message with a return error parameter set to "SystemFailure". 

5.6.8.2.4 Adding a party to tine conference 

When the MSC Server receives a BuildMPTY from a UE with a conference on hold and separate active or waiting call 
as described in 3GPP TS 24.084 [34], the MSC Server shall: 

- invite the remote party to the conference as described in 3GPP TS 24.292 [7]; and 
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- send an UPDATE or re-INVITE request to resume the held conference as described in subclause 5 .6.3 . 1 .2. 

5.6.8.2.5 Terminating tine conference or disconnecting a party from tine conference 

When the MSC Server receives a DISCONNECT message from a UE with an established conference, with a transaction 
identifier corresponding to a specific remote party, the MSC Server shall start a conference termination specific timer. 
While the timer is running, MSC Server shall collect potential further DISCONNECT messages from the UE, with valid 
transaction identifiers, corresponding to other remote parties. These additional DISCONNECT messages shall not 
trigger starting a new timer and shall not restart the timer. 

NOTE 1: The value for the conference termination timer is implementation specific. The timer has to be long 

enough to allow that the UE encodes and transmits all the DISCONNECT messages to the MSC Server 
but it should be kept short so that the DISCONNECT messages used for disconnecting a single 
conference participant are not delayed too long. A value around 1 sec is seen as satisfactory. 

When the timer expires, MSC Server shall examine, whether it has received a DISCONNECT message corresponding 
to all remote parties that have been participants of the estabUshed conference and depending on that shall act as follows: 

- If a DISCONNECT messages has been received for each participant, the MSC Server shall send a BYE request 
to the conference-URI. 

NOTE 2: A complete set of DISCONNECT messages is interpreted as request to terminate the established 

conference. The BYE request will lead to a termination of the conference by the conference focus, after 
removal all the participants, as described in 3GPP TS 24.147 [36], subclause 5.3.2.7. 

- Otherwise, the MSC Server shall generate a separate REFER request for each DISCONNECT message to 
remove the corresponding party/parties from the conference as specified in 3GPP TS 24.147 [36] subclause 
5.3.1.6.3, with the Refer-To header of the REFER request set to the address of the conference participant being 
removed and also containing a "method" URI parameter set to "BYE". 

NOTE 3: The MSC Server thus treats the DISCONNECT message(s) received before timer expiry as the user"s 
request for discormecting the party/parties belonging to the received transaction identity/identities. 

5.6.8.2.6 Receipt of a SplitlVIPTY message 

When the MSC Server receives a SphtMPTY request from the UE, the MSC Server shall send a FACILITY message 
with a return error parameter set to "ss-NotAvaUable". 

5.6.8.3 MSC Server as conference participant 
5.6.8.3.1 Receipt of invitation to conference 

5.6.8.3.1.1 General 

The methods by which the MSC Server, on behalf of the UE, can be invited to a conference are described in 3GPP TS 
24.605 [35] subclause 4.5.2.1.2 and 3GPP TS 24.147 [36] subclause 5.3.1.5. 

5.6.8.3. 1 .2 Receipt of REFER within a dialog 

Upon receipt of a REFER request within a dialog, the MSC Server shall act as a transferee on behalf of the UE as 
specified in subclause 5.6.7.3.1. 

NOTE 1 : If the Refer-To header of the REFER request contains a conference URI, this will result in the user 
joining a conference. 

NOTE 2: CS domain access signalling as specified in 3GPP TS 24.091 [32] does not provide a mechanism to 

present the transfer request to the transferee for authorization of the transfer. Automatic acceptance and 
execution of the REFER request by the MSC Server can therefore pose a security risk or have unwanted 
charging consequences. Acceptance of REFER requests is therefore subject to operator policy, which is 
outside the scope of the present document. 
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5.6.8.3. 1 .3 Receipt of REFER outside a dialog 

If the MSC Server does not support accepting REFER requests on behalf of the UE per operator policy, then the MSC 
Server shall return a 403 Forbidden response. 

Support for the MSC Server, on behalf of a UE, joining a conference in this manner requires that the MSC Server shall: 

- initiate a terminating call leg toward the UE in accordance with 3GPP TS 24.008 [3]; and 

NOTE: If the user is involved in a call, then the call waiting procedures described in 3GPP TS 24.008 [3] and 
3GPPTS 24.083 [26] apply. 

- initiate an originating call toward the URI identified in the Refer-To header (e.g. the conference URI); and 

- combine these two call legs into a single call. 

Support for this method of joining a conference may be provided as an implementation option but is outside the scope 
of the present document. 



5.6.8.3.1 .4 Receipt of INVITE 

NOTE: Subclause 5.4.2 contains general applicable procedures executed upon receipt of an initial INVITE 
request. 

If an INVITE request is received, the MSC Server shall act as follows: 

- if the user is idle, the MSC Server shall act according to the mobile terminating call set up procedures specified 
in subclause 5.4; 

if the user is engaged in an established SIP dialog and the INVITE request contains a Replaces header field 
corresponding to the estabhshed dialog, the MSC Server act as a transfer target on behalf of the UE as specified 
in subclause 5.6.7.4; or 

- if the user is engaged in an established SIP dialog and the INVITE request does not contain a Replaces header 
field corresponding to the established dialog, the MSC Server shall follow the conmiunication waiting 
procedures described in subclause 5.6.4.1. 



5.6.8.3.2 Notification of conference invocation 

If the MSC Server received a non-zero SS screening indicator from the UE as defined in 3GPP TS 24.080 [29], then 
upon joining a conference on behalf of a UE, the MSC Server may send a FACILITY message to the UE indicating a 
multiparty call has been invoked as specified in 3GPP TS 24.084 [34]. 

NOTE: If the MSC Server was invited to the conference via reception of a REFER request as specified in 3GPP 
TS 24.147 [36] subclause 5.3.1.5.2, the MSC Server is not able to distinguish between REFER requests 
for the conferencing service and REFER requests for the ECT service. In such cases, the MSC Server will 
not know which SS operation to indicate in the FACILITY message. Handling of this scenario is 
implementation specific. 



5.6.9 Customized Alerting Tones (CAT) 



5.6.9.1 General 

The following subclauses describe the MSC Server interworking behaviour related to the Customized Alerting Tones 

(CAT) services defined in 3GPP TS 24.182 [51]. 

Based on operator options, one of three different models described in 3GPP TS 24.182 [51] is used in an IM CN 
subsystem to provide the CAT service. The CAT interworking procedures at the MSC server differ between these 
models and are described seperately for each model in the subsequent sub-clauses. Support of the interworking 
procedures for each of those models is optional. 

No special interworking procedures for the CAT service when MSC server receive a terminating request from IMS 
network are required. 
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5.6.9.2 Early session model 
5.6.9.2.1 Originating request 

If the MSC server supports early-sesssion as a network option, upon receiving an incoming SETUP message, before the 
MSG server sending the generated SIP INVITE request as described in subclause 5.3.3, it shall include the option tag 
"early-session", as defined in IETF RFC 3959 [50], in Supported header field. 

After receiving the first SIP 18x response including an early-session SDP, the MSC server shall send the ALERTING 
message as described in 3GPP TS 24.008 [3], then the MSC server shall follow the same procedure as described for 
MGCF in 3GPP TS 29.163 subclause 7.5.13 [46J to negotiate with IMS side for early-session and normal session 
estabUshment. 

5.6.9.3 Forking model 

Interworking at MSC server follows the basic call interworking procedures. Support of the P-Early-Media header field 
and related procedures as described in subclause 5.3.4a and subclause 5.3.4b are required in addition. 

5.6.9.4 Gateway model 

Interworking at MSC server follows the basic call interworking procedures. Support of the P-Early-Media header field 
and related procedures as described in subclause 5.3.4a and subclause 5.3.4b are required in addition. 

5.7 Supplementary Service Configuration 

5.7.1 General 

The MSC Server may support the interworking between call independent supplementary service signalling described in 
3GPP TS 24.010 [41] and the XCAP application usage for manipulating supplementary services data described in 3GPP 
TS 24.623 [42]. This MSC Server may support this interworking for any subset of the supplementary services within 
the scope of the present document. This interworking shall only be performed for the TSl 1 service code. If the MSC 
Server interworks a supplementary service invoke operation received via NAS signalling to the IM CN subsystem, the 
MSC Server shall not also transfer the received information to the VLR as described in 3GPP TS 29.002 [20]. This 
interworking is defined in the following subclauses. 

NOTE: This interworking is subject to the limitations inherited by the NAS signalling procedures defined for 
each supplementary service. For example, if no NAS signalUng procedure is defined for registration, 
erasure, activation, deactivation or interrogation of a particular supplementary service that is being 
controlled by the IM CN subsystem, then no interworking procedme is defined. 

5.7.2 Receipt of REGISTER message 

Upon receipt of a REGISTER message for a supplementary service whose interworking is within the scope of the 
present document, the MSC Server shall generate the appropriate HTTP request according to table 5.7.2. 1 if 
supplementary service configuration interworking for that supplementary service is supported by the MSC Server. 



Table 5.7.2.1 : Mapping REGISTER / FACILITY to HTTP request 



invoke operation in tiie REGISTER message 


HTTP request 


RegisterSS 


PUT 


ActivateSS 


PUT 


DeactivateSS 


PUT 


InterrogateSS 


GET 


EraseSS 


PUT 
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NOTE: Not all invoke operations are valid for all supplementary services. Interworking definitions for each 

supplementary service are only provided for invoke operations explicitly defined for each supplementary 
service. 

The interworking of message contents for each supplementary service is described in subclause 5.7.4. 

5.7.3 Receipt of HTTP response 

Upon receipt of an HTTP response to a previously sent HTTP request as described in subclause 5.7.2, the MSC Server 
shall terminate the appropriate service interaction by sending a RELEASE COMPLETE message. The interworking of 
message contents for each supplementary service is described in subclause 5.7.4. 

5.7.4 Service data interworking 

5.7.4.1 Originating identification presentation/restriction (OIP/OIR) 

5.7.4.1.1 Registration/erasure 

The OIP/OIR services require no registration. Erasure is not applicable. 

5.7.4.1 .2 Activation/deactivation 

The OIP/OIR services are activated at provisioning and deactivated at withdrawal and therefore require no interworking 
at the MSC Server. 

5.7.4.1.3 Interrogation 

If the MSC Sever supports supplementary service configuration interworking for the OIP/OIR services, the 
interworking procedures in this subclause shall be applied. 

When the MSC Server receives a REGISTER message with an InterrogateSS invoke operation for the CLIP or CLIR 

supplementary service code as described in 3GPP TS 24.081 [12], the MSC Server shall generate and send an HTTP 
GET request to fetch the instance of the Originating Identity document as specified in 3GPP TS 24.623 [42]. 

Upon receiving a response to the HTTP GET request, the MSC Server shall apply the following interworking: 

- If a 200 OK response is received which includes an Originating Identity document as defined in 3GPP TS 24.607 
[43], the MSC Server shall send a RELEASE COMPLETE message as follows: 

- If the Originating Identity document indicates the interrogated service (CLIP/OIP or CLIR/OIR) is active, the 
MSC Server shall indicate an SS-Status of provisioned and active; or 

- If the Originating Identity document indicates the interrogated service (CLIP/OIP or CLIR/OIR) service is 
not active, the MSC Server shall indicate an SS-Status of provisioned but not active; 

- If the CLIR/OIR service was interrogated, then the following additional interworking shall be applied: 

- If there is a "default-behaviour" attribute included and set to "presentation-restricted" in the Originating 
Identity document, the MSC Server shiill set the CLI Restriction Option parameter to indicate Temporary 

(Default Restricted); 

- If there is a "default-behaviour" attribute included and set to "presentation-not-restricted" in the 
Originating Identity document the MSC Server shall set the CLI Restriction Option parameter to 
Temporary (Default Allowed); 

If a non 200 OK response is received or if a 200 OK response is received which does not include an Originating 
Identity document, the MSC Server shall send a RELEASE COMPLETE message with an implementation- 
specific error code. 
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5.7.4.2 Terminating identification presentation/restriction (TIP/TIR) 

5.7.4.2.1 Registration/erasure 

The TIP/TIR services require no registration. Erasure is not applicable. 

5.7.4.2.2 Activation/deactivation 

The TIP/TIR services are activated at provisioning and deactivated at withdrawal and therefore require no interworking 
at the MSG Server. 

5.7.4.2.3 Interrogation 

If the MSG Sever supports supplementary service configuration interworking for the TIP/TIR services, the interworking 
procedures in this subclause shall be applied. 

When the MSG Server receives a REGISTER message with an InterrogateSS invoke operation for the GOLP or GOLR 
supplementary service code as described in 3GPP TS 24.081 [12], the MSG Server shall generate an HTTP GET 
request to fetch the instance of the Terminating Identity document as specified in 3GPP TS 24.623 [42]. 

Upon receiving a response to the HTTP GET request, the MSG Server shall apply the following interworking: 

If a 200 OK response is received which includes a Terminating Identity document as defined in 3GPP TS 24.608 
[14], the MSG Server shall send a RELEASE GOMPLETE message as follows: 

- If the Terminating Identity document indicates the interrogated service (GOLP/TIP or GOLR/TIR) is active, 
the MSG Server shall indicate an SS-Status of provisioned and active; or 

- If the Terminating Identity document indicates the interrogated service (GOLP/TIP or GOLR/TIR) service is 
not active, the MSG Server shall indicate an SS-Status of provisioned but not active; 

NOTE: GS signalling defined in 3GPP TS 24.081 [12] does not allow for the temporary mode status of the GOLR 
service to be sent to the UE. 

If a non 200 OK response is received or if a 200 OK response is received which does not include a Terminating 
Identity document, the MSG Server shall send a RELEASE GOMPLETE message with an implementation- 
specific error code. 

5.7.4.3 Communication Hold (HOLD) 

Gonfiguration of the HOLD service involves no signalhng and therefore requires no interworking at the MSG Server. 

5.7.4.4 Communication Waiting (CW) 

5.7.4.4.1 Registration/erasure 

The GW service requires no registration. Erasure is not applicable. 

5.7.4.4.2 Activation/deactivation 

If the MSG Sever supports supplementary service configuration interworking for the GW service, the interworking 
procedures in this subclause shall be applied. 

When the MSG Server receives a REGISTER message with an ActivateSS or DeactivateSS invoke operation for the 
GW supplementary service code as described in 3GPP TS 24.083 [26], the MSG Server shall include an instance of the 
call waiting document described in 3GPP TS 24.615 [44] in the HTTP PUT request as follows: 

- If the invoke operation is ActivateSS, the MSG Server shall set the "active" attribute to "true" ; 

- If the invoke operation is DeactivateSS, the MSG Server shall set the "active" attribute to "false". 
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5.7.4.4.3 Interrogation 

If the MSC Sever supports supplementary service configuration interworking for the CW service, the interworking 
procedures in this subclause shall be applied. 

When the MSC Server receives a REGISTER message with an InterrogateSS invoke operation for the CW 
supplementary service code as described in 3GPP TS 24.083 [26], the MSC Server shall generate and send an HTTP 
GET request to fetch the instance of the call waiting document as specified in 3GPP TS 24.623 [42]. 

When a response to the HTTP GET request is received, the MSC Server shall apply the following interworking: 

- If a 200 OK is received which includes a call waiting document as defined in 3GPP TS 24.615 [44], the MSC 
Server shall send a RELEASE COMPLETE message as follows: 

- If the call waiting document includes an "active" attribute set to "true", the MSC Server shall indicate an SS- 
Status of provisioned and active; 

If the call waiting document includes an "active" attribute set to "fidse", the MSC Server shall indicate an SS- 
Status of provisioned but not active; 

- If a non 200 OK response is received or if a 200 OK response is received which does not include a call waiting 
document, the MSC Server shall send a RELEASE COMPLETE message with an implementation- specific error 
code. 

5.7.4.5 Communication Barring (CB) 

5.7.4.5.1 Registration/erasure 

When the MSC Server receives a REGISTER message with a RegisterSS invoke operation for any call barring 
supplementary service code as described in 3GPP TS 24.088 [30], the MSC Server shall send a RELEASE 
COMPLETE message with an implementation-specific error code. 

NOTE: This is because the password registration procedures required to support CB registration using NAS 
signalling do not have equivalencies in 3GPP TS 24.623 [42] or 3GPP TS 24.61 1 [31]. 

Erasure of the CB service is not specified for NAS signalling in 3GPP TS 24.088 [30], therefore interworking 
procedures for service erasure are not apphcable. 

5.7.4.5.2 Activation/deactivation 

When the MSC Server receives a REGISTER message with an ActivateSS or DeactivateSS invoke operation for any 
call barring supplementary service code as described in 3GPP TS 24.088 [30], the MSC Server shall send a RELEASE 
COMPLETE message with an implementation- specific error code. 

NOTE: This is because the password registration procedures required to support CB activation and deactivation 
using NAS signalling do not have equivalencies in 3GPP TS 24.623 [42] or 3GPP TS 24.611 [31]. 

5.7.4.5.3 Interrogation 

If the MSC Server supports supplementary service configuration interworking for the CB service, the interworking 
procedures in this subclause shall be applied. 

When the MSC Server receives a REGISTER message with an InterrogateSS invoke operation for the BAOC or BAIC 

supplementary service code as described in 3GPP TS 24.082 [24], the MSC Server shall generate and send an HTTP 
GET request to fetch the instance of the Communication Barring document as specified in 3GPP TS 24.623 [42]. 

When a response to the HTTP GET request is received, the MSC Server shall apply the following interworking: 

If a 200 OK response is received which includes a Communication Barring document as defined in 3GPP TS 
24.611 [31], the MSC Server shall send a RELEASE COMPLETE message as follows: 

- If the Communication Barring document indicates the call barring service being interrogated is active, the 
MSC Server shall include a BasicServiceCode set to the TSll service code; 
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If the Communication Barring document indicates the call barring service being interrogated is not active, the 
MSC Server shall include an SS-Status of deactivated; 

- If a non 200 OK response is received or if a 200 OK response is received which does not include a 
Communication Barring document, the MSC Server shall send a RELEASE COMPLETE message with an 
implementation-specific error code. 

When the MSC Server receives a REGISTER message with an InterrogateSS invoke operation for the BOIC, BOIC- 
exHC or BIC-Roam supplementary service code as described in 3GPP TS 24.082 [24], the MSC Server shall send a 
RELEASE COMPLETE message with an implementation-specific error code as these supplementary service codes 
cannot be mapped to the CB rules defined in 3GPP TS 24.61 1 [31]. 

5.7.4.6 Communication Diversion (CDIV) 
5.7.4.6.1 Registration 

If the MSC Server supports supplementary service configuration interworking for the CDIV service, the interworking 
procedures in this subclause shall be applied. 

When the MSC Server receives a REGISTER message with a RegisterSS invoke operation for a supplementary service 
code Usted below, the MSC Server shall include Communication Diversion document as described in 3GPP TS 24.604 
[23] in the HTTP PUT request as follows: 

The MSC Server shall set the active attribute to "true"; 

- If the supplementary service code is CPU as described in 3GPP TS 24.082 [24], the MSC Server shall include an 
empty rule set; 

- If the supplementary service code is CFB as described in 3GPP TS 24.082 [24], the MSC Server shall include a 
forwarding rule for the busy condition defined in 3GPP TS 24.604 [23]; 

If the supplementary service code is CFNRy as described in 3GPP TS 24.082 [24], the MSC Server shall include 
a forwarding rule for the no-answer condition defined in 3GPP TS 24.604 [23]; 

If the supplementary service code is CFNRc as described in 3GPP TS 24.082 [24], the MSC Server shall include 
a forwarding rule for the not-reachable condition defined in 3GPP TS 24.604 [23]; 

- The MSC Server shall include a "target" element set to the TEL URI representation of the ForwardedToNumber 
parameter received in the REGISTER message. The TEL URI shall be constructed as described in subclause 
5.3.3.2. 

NOTE: The Communication Diversion document described in 3GPP TS 24.604 [23] defines XML elements 

which have no functional equivalent in the service configuration signalling defined in 3GPP TS 24.082 
[24]. The inclusion of these elements and the values assigned to them is subject to operator pohcy. 

The MSC Server shall store a copy of the Communication Diversion document until the HTTP PUT response is 
received and processed. 

When a response to the HTTP PUT request is received, the MSC Server shall apply the following interworking: 

- If a 200 OK is received, the MSC Server shall send a RELEASE COMPLETE message as follows: 

The MSC Server shall indicate an SS-Status of provisioned and active; 

- The MSC Server shall set the ForwardedToNumber parameter to the "target" element in the stored 
Communication Diversion document. 

If a non 200 OK response is received or if a 200 OK response is received which does not include a 
Communication Diversion document, the MSC Server shall send a RELEASE COMPLETE message with an 
implementation-specific error code. 
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5.7.4.6.1a Erasure 

If the MSC Server supports supplementary service configuration interworking for the CDIV service, the interworking 
procedures in this subclause shall be applied. 

When the MSC Server receives a REGISTER message with an EraseSS invoke operation for a supplementary service 
listed below, the MSC Server shall first fetch the instance of the Communication Diversion document as described in 
subclause 5.7.4.6.3. If the MSC Server is unable to fetch the Communication Diversion document, the MSC Server 
shall send a RELEASE COMPLETE message with an implementation- specific error code. 

The MSC Server shall then include the Communication Diversion document as described in 3GPP TS 24.604 [23] in an 
HTTP PUT request, modified as follows: 

- If the supplementary service code is CFU, the MSC Server shall remove the empty rule set, if present; 

If the supplementary service code is CFB, the MSC Server shall remove the forwarding rule for the busy 
condition defined in 3GPP TS 24.604 [23], if present; 

- If the supplementary service code is CFNRy, the MSC Server shall remove the forwarding rule for the no- 
answer condition defined in 3GPP TS 24.604 [23], if present; 

- If the supplementary service code is CFNRc, the MSC Server shall remove the forwarding rule for the not- 
reachable condition defined in 3GPP TS 24.604 [23], if present; 

- If the supplementary service code is "all forwarding SS", the MSC Server shall remove all forwarding rules 
described above. 

When a response to the HTTP PUT request is received, the MSC Server shall apply the following interworking: 

- If a 200 OK is received, the MSC Server shall send a RELEASE COMPLETE message as follows: 

- If an SS-Status parameter is required as specified in 3GPP TS 24.082 [24] subclause 1 .3 . 1 , the MSC Server 
shall indicate an SS-Status of not active; 

If a non 200 OK response is received or if a 200 OK response is received which does not include a 
Communication Diversion document, the MSC Server shall send a RELEASE COMPLETE message with an 
implementation-specific error code. 

5.7.4.6.2 Activation/deactivation 

If the MSC Sever supports supplementary service configuration interworking for the CDIV service, the interworking 
procedures in this subclause shall be applied. 

When the MSC Server receives a REGISTER message with an ActivateSS or DeactivateSS invoke operation for the 
CFU, CFB, CFNRy or CFNRc supplementary service code as described in 3GPP TS 24.082 [24], the MSC Server shall 
include a Communication Diversion document as described in 3GPP TS 24.604 [23] in the HTTP PUT request as 
follows: 

- If the invoke operation is ActivateSS, the MSC Server shall set the "active" attribute to "true"; 

- If the invoke operation is DeactivateSS, the MSC Server shall set the "active" attribute to "false"; 

- If the supplementary service code is CFU as described in 3GPP TS 24.082 [24], the MSC Server shall include an 
empty rule set; 

If the supplementary service code is CFB as described in 3GPP TS 24.082 [24], the MSC Server shall include a 
forwarding rule for the busy condition defined in 3GPP TS 24.604 [23]; 

- If the supplementary service code is CFNRy as described in 3GPP TS 24.082 [24], the MSC Server shall include 
a forwarding rule for the no-answer condition defined in 3GPP TS 24.604 [23]; 

- If the supplementary service code is CFNRc as described in 3GPP TS 24.082 [24], the MSC Server shall include 
a forwarding rule for the not-reachable condition defined in 3GPP TS 24.604 [23]; 
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NOTE: The Communication Diversion document described in 3GPP TS 24.604 [23] defines XML elements 

which have no functional equivalent in the service configuration signalling defined in 3GPP TS 24.082 
[24]. The inclusion of these elements and the values assigned to them is subject to operator poUcy. 

The MSC Server shall store a copy of the Communication Diversion document until the HTTP PUT response is 
received and processed. 

When a response to the HTTP PUT request is received, the MSC Server shall apply the following interworking: 
- If a 200 OK is received, the MSC Server shall send a RELEASE COMPLETE message as follows: 

- If the "active" attribute in the stored Communication Diversion document is set to "true", the MSC Server 
shall indicate an SS-Status of provisioned and active; 

- If the "active" attribute in the stored Communication Diversion document is set to "false", the MSC Server 
shall indicate an SS-Status of provisioned but not active; 

If a non 200 OK response is received or if a 200 OK response is received which does not include a 
Communication Diversion document, the MSC Server shall send a RELEASE COMPLETE message with an 
implementation-specific error code. 

5.7.4.6.3 Interrogation 

If the MSC Sever supports supplementary service configuration interworking for the CDIV service, the interworking 

procedures in this subclause shall be applied. 

When the MSC Server receives a REGISTER message with an InterrogateSS invoke operation for the CFU, CFB, 
CFNRy or CFNRc supplementary service code as described in 3GPP TS 24.082 [24], the MSC Server shall generate 
and send an HTTP GET request to fetch the instance of the Communication Diversion document as specified in 3GPP 
TS 24.604 [23]. 

When a response to the HTTP GET request is received, the MSC Server shall apply the following interworking: 

If a 200 OK is received which includes a Communication Diversion document as defined in 3GPP TS 24.604 
[23], the MSC Server shall send a RELEASE COMPLETE message as follows: 

- If the Communication Diversion document indicates the call forwarding service being interrogated is active, 
the MSC Server shall indicate an SS-Status of provisioned and active; 

- If the Communication Diversion document indicates the call forwarding service being interrogated is not 
active, the MSC Server shall indicate an SS-Status of provisioned but not active; 

- If the Communication Diversion document contains a "target" attribute containing a TEL URI, the MSC 
Server shall set the ForwardedToNumber parameter to the TEL URI. 

If a non 200 OK response is received or if a 200 OK response is received which does not include a 
Communication Diversion document, the MSC Server shall send a RELEASE COMPLETE message with an 
implementation-specific error code. 

5.7.4.7 Explicit Communication Transfer (ECT) 

Configuration of the ECT service involves no signalUng and therefore requires no interworking at the MSC Server. 

5.7.4.8 Conference (CONF) 

Configuration of the CONF service involves no signalling and therefore requires no interworking at the MSC Server. 
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5.8 Handover / Relocation 



5.8.1 Intra-MSC Handover/Relocation 

The MSC Server applies the procedures specified in 3GPP TS 23.009 [37] for Intra-MSC handover/relocation in the CS 
domain. After the handover/relocation is completed, the MSC Server shall process the interworking between the NAS 
signalling with the SIP signalling as specified in sub-clauses 5.3 through 5.6. 



5.8.2 Inter-MSC Handover/Relocation 

The MSC Server applies the procedures specified in 3GPP TS 23.009 [37] for Inter-MSC handover/relocation in the CS 
domain. After the handover/relocation is completed, the anchor MSC Server shall process the interworking between the 
NAS signalhng with the SIP signalling as specified in sub-clauses 5.3 through 5.6. The NAS signalling contained in the 
MAP messages is passed between the anchored MSC Server and the target MSC Server through the E interface as 
specified in 3GPP TS 29.002 [20]. 



6 User plane interworking 
6.1 General 

The following subclauses define the interworking performed by the CS-MGW between the IM CN subsystem and CS 
domain access. The interworking between the Mb reference point and the user plane portions of the luCS and A 
reference points is specified. 



6.2 luCS to Mb interworking 
6.2.1 Interworking with transcoding 

Figure 6.2.1.1 shows the user plane protocol stacks for the luCS and IM CN subsystem interworking when transcoding 
is required. 
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Figure 6.2.1.1 : luCS to Mb protocol stack (transcoding) 

luFP is defined is defined in 3GPP TS 25.415 [16]. luCS layer 2 and layer 3 are defined in 3GPP TS 25.414 [15]. The 
luCS layer 1 is defined in 3GPP TS 25.411 [17]. 
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6.2.2 Transcoder-less interworking 

Figure 6.2.2.1 shows the user plane protocol stacks for the interworking when the same AMR configuration is used on 
the luCS and Mb reference points and transcoding is not required. 
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Figure 6.2.2.1 : luCS to Mb protocol stack (no transcoding) 

If no transcoder is inserted, the CS-MGW shall interwork procedures between the luCS and Mb reference points as 
specified in 3GPP TS 29.414 [18] subclause 7.4. 

6.3 TDM-based A-interface to Mb interworking 
6.3.1 Interworking with transcoding 

Figure 6.3. 1 . 1 shows the user plane protocol stacks for the TDM-based A and Mb reference point interworking when 
transcoding is required. 
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Figure 6.3.1.1 : TDIUl-based A to lUlb protocol stack (transcoding) 

Layer 1 for the TDM-based A-interface is defined in 3GPP TS 48.004 [19]. 
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6.3.2 Transcoder-less interworking 

Figure 6.3.2.1 shows the user plane protocol stacks for the interworking when the same codec is used on the TDM- 
based A and Mb reference points and transcoding is not required. 
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Figure 6.3.2.1 : TDM-based A to Mb protocol stack (no transcoding) 

6.4 IP-based A-interface to Mb interworking 
6.4.1 Interworking with transcoding 

Figure 6.4.1.1 shows the user plane protocol stacks for the IP-based A and Mb reference point interworking when 
transcoding is required. 
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Figure 6.4.1.1 : IP-based A to Mb protocol stack (transcoding) 

The IP-based A-interface user plane transport is defined in 3 GPP TS 48.103 [38]. 
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6.4.2 Transcoder-less interworking 

Figure 6.4.2.1 shows the user plane protocol stacks for the interworking when the same codec is used on the IP-based A 
and Mb reference points and transcoding is not required. 
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Figure 6.4.2.1 : IP-based A to Mb protocol stack (no transcoding) 

The IP-based A-interface user plane transport is defined in 3 GPP TS 48.103 [38]. 

7 MSG Server - CS-MGW interaction 

7.1 Mobile originated call 

7.1.1 CS-MGW selection 

The MSG Server shall select a GS-MGW for the bearer connection before it performs the access bearer assignment or 
the network side connection point reservation. 

7.1 .2 IMS session side establisliment 

The MSG Server shall either select bearer characteristics or request the GS-MGW to select and provide the bearer 
characteristics for the network side session before sending the INVITE request. The MSG Server shall use the Reserve 
RTP Gonnection Point procedure as defined in 3GPP TS 29.232 [1 1]. 

Within this procedure, the MSG Server shall indicate the received speech codecs from the UE and the MSG Server may 
indicate some configured speech codec(s) to the GS-MGW and request a local IP address and UDP port from the 
GS-MGW and the MSG Server may also indicate that the IP interface type is for MboIP as defined in 3GPP TS 29.232 
[11]. The local IP address and UDP port are used by the GS-MGW to receive user plane data. 

The GS-MGW shall reply to the MSG Server with the selected local speech codec(s) and the selected local IP address 
and UDP port(s). 

After the succeeding node has provided the SDP answer, the MSG Server uses the Gonfigure RTP Resources procedure 
as defined in 3GPP TS 29.232 [1 1] to request the GS-MGW to configure the bearer. 
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7.1.3 



Access bearer establishment 



7.1.3.1 



General 



The way the MSC Server media gateway interaction is carried out depends on the characteristics of the access bearer 
network. 



The MSC Server and the CS-MGW shall act in accordance with subclause 6.1.3 in 3GPP TS 23.205 [39] and apply the 
coding in accordance with 3GPP TS 29.232 [11]. 

7.1 .3.3 A interface over IP 

The MSC Server and the CS-MGW shall act in accordance with subclause 6.1.5 in 3GPP TS 23.205 [39] and apply the 
coding in accordance with 3GPP TS 29.232 [11]. 

7.1 .3.4 A interface over TDM 

The MSC Server and the CS-MGW shall act in accordance with subclause 6.1.1.4 in 3GPP TS 23.205 [39] and apply 
the coding in accordance with 3GPP TS 29.232 [11]. 

7.1 .3.5 lu over UTRAN and GERAN 

The MSC Server and the CS-MGW shall act in accordance with subclause 6.1.1.4 in 3GPP TS 23.205 [39] and apply 
the coding in accordance with 3GPP TS 29.232 [11]. 

7.1.4 Apply ringing tone 

If the condition as defined in subclause 5.3.5 is fulfilled the MSC Server shall instruct the CS-MGW to send ringing 
tone towards the calling party. In this case the MSC Server shall use the Send Tone procedme in accordance with 3GPP 
TS 23.205 [39] and 3GPPTS 29.232 [11]. 

If the MSC Server wishes to stop sending the ringing tone e.g. due to the receipt of a 200 OK response to the INVITE 
request the MSC Server shall apply the Stop Tone procedure as defined in 3GPP TS 23.205 [39] and 3GPP TS 29.232 
[11]. 

7.1 .5 Through connection 

If the MSC Server wants to configure the CS-MGW so that the bearer will be through-connected in the backward 
direction the MSC Server shall: 

- use Change Through-Connection procedure as defined in 3GPP TS 29.232 [11] during any one of the Prepare 
Bearer and Reserve Circuit procedures as defined in 3GPP TS 29.232 [11]; or 

use Configure the RTF Connection Point procedure as defined in 3GPP TS 29.232 [11] during Prepare IP 
bearer procedure as defined in 3GPP TS 29.232 1 1 1 1. 

If the MSC Server wants to configure the CS-MGW so that the bearer will be both-way through connected the MSC 
Server shall use Change Through-Connection procedure as defined in 3GPP TS 29.232 [1 IJ. 

7.1 .5a Handling of Forking 

The procedures described in subclauses 7.1.1 to 7.1.6 shall be apphed with the addition that the MSC Server and the 
CS-MGW shall act in accordance with subclauses 9.2.3.4.1 to 9.2.3.4.4 in 3GPP TS 29.163 [46]. 

NOTE: For the references to 3GPP TS 29.163 [46], the O-MGCF and 1-MGCF in 3GPP TS 29.163 [46] is to be 
imderstood as MSC Server, the IM-MGW is to be understood as CS-MGW, and the Configure IMS 
Resources procedure is to be understood as Configure RTP Resources procedure. 



7.1.3.2 



lu interface on IP 



ETSI 



3GPP TS 29.292 version 10.2.0 Release 10 



49 



ETSI TS 129 292 VI 0.2.0 (2012-03) 



7.1 .6 Failure handling in MSG server 

If any procedure between the MSC Server and the CS-MGW has not completed successfully or the MSG Server 
receives a Bearer Released procedure from the CS-MGW the procedure in accordance with subclause 6.1.1.12 of 3GPP 
TS 23.231 [40] and 3GPP TS 29.232 [1 1] shall be applied. 

7.2 Mobile ternninated call 

7.2.1 CS-MGW selection 

The MSC Server shall select an CS-MGW for the bearer connection before it performs the network side bearer 
establishment or the access bearer assignment The selection of the CS-MGW does not take place before the call 
proceeding has been received by the MSC Server. 

7.2.2 Network side session establishment 

The MSC Server shall request the CS-MGW to prepare for the network side session establishment using the Reserve 
RTP Connection Point and Configure RTP Resources procedure as specified in 3GPP TS 23.205 [39] and 3GPP TS 
29.232 [11]. Within this procedure, the MSC Server shall indicate the received speech codecs from the remote UE and 
request a local IP address and UDP port from the CS-MGW and the MSC Server may also indicate that the IP interface 
type is for MboIP as defined in 3GPP TS 29.232 1 11 1. The local IP address and UDP ports are used by the CS-MGW to 
receive user plane data. The MSC Server shall include the local IP address and UDP port number in the SDP answer for 
the selected codec. 

7.2.3 Access bearer assignment 

7.2.3.1 General 

The way the MSC Server-CS-MGW interaction is carried out depends on the characteristics of the access bearer 
network. 

7.2.3.2 lu interface on IP 

The MSC Server and the CS-MGW shall act in accordance with subclause 6.2.3 in 3GPP TS 23.205 [39] and apply the 
coding in accordance with 3GPP TS 29.232 [11]. 

7.2.3.3 A interface over IP 

The MSC Server and the CS-MGW shall act in accordance with subclause 6.2.4 in 3GPP TS 23.205 [39] and apply the 
coding in accordance with 3GPP TS 29.232 [11]. 

7.2.3.4 A interface over TDM 

The MSC Server and the CS-MGW shall act in accordance with subclause 6.2.2.2.4 in 3GPP TS 23.205 [39] and apply 
the coding in accordance with 3GPP TS 29.232 [11]. 

7.2.3.5 lu over UTRAN and GERAN 

The MSC Server and the CS-MGW shall act in accordance with subclause 6.2.2.2.4 in 3GPP TS 23.205 [39] and apply 
the coding in accordance with 3GPP TS 29.232 [11]. 

7.2.4 Apply ringing tone 

If the condition as defined in subclause 5.4.7 is fulfilled the MSC Server shall instruct the CS-MGW to send ringing 
tone towards the calling party. In this case the MSC Server shall use the Send Tone procedure in accordance with 3GPP 
TS 23.205 [39] and 3GPPTS 29.232 [11]. 
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If the MSC Server wishes to stop sending the ringing tone, e.g. due to receipt of the CONNECT message, the MSC 
Server shall apply the Stop Tone procedure as defined in 3GPP TS 23.205 [39] and 3GPP TS 29.232 [11]. 

7.2.5 Through connection 

If the MSC Server wants to configure the CS-MGW so that the bearer will not be through-connected the MSC Server 
shall: 

use Change Through-Connection procedure as defined in 3GPP TS 29.232 [11] during any one of the Prepare 
Bearer and Reserve Circuit procedures as defined in TS 3GPP 29.232 [1 1]; or 

use Configure the RTP Connection Point procedure as defined in 3GPP TS 29.232 [1 l]during Prepare IP bearer 
procedure as defined in 3GPP TS 29.232 [11]. 

If the MSC Server wants to configure the CS-MGW so that the bearer will be both-way through connected the MSC 
Server shall use the Change Through-Connection procedure as defined in 3GPP TS 29.232 [11]. 

7.2.6 Announcement 

If the MSC Server wants to provide an announcement, e.g. when the condition in subclause 5.4.7 is fiilfiUed, the MSC 

Server shall instruct the CS-MGW to send an announcement. In this case the MSC Server shall use the Play 
Announcement procedure in accordance with 3GPP TS 23.205 [39] and 3GPP TS 29.232 [11]. 

If the MSC Server wishes to stop the sending of an announcement the MSC Server shall apply the Stop Announcement 
procedure as defined in 3GPP TS 23.205 [39] and 3GPP TS 29.232 [11]. 

7.2.7 Failure handling in the MSC server 

If any procedure between the MSC Server and the CS-MGW has not completed successfully or the MSC Server 
receives a Bearer Released procedure from the CS-MGW the procedure in accordance with subclause 6.2. 1 .3. 13 of 
3GPP TS 23.231 [40] and 3GPP TS 29.232 [11] shall be applied. 

7.3 Call clearing 

7.3.1 Clearing received from the network 

7.3.1.1 Access bearer clearing 

Once the call clearing and the release of the associated radio resources have been completed, the MSC Server releases 
any CS-MGW allocated resources for the access side. If any resources were seized in the CS-MGW, the MSC Server 
uses the Release Termination procedure as specified in 3GPP TS 29.232 [11] to request the CS-MGW to remove the 
access side bearer termination. 

7.3.1 .2 Network side clearing 

If the MSC Server requires to release resources due to the receipt of a BYE or CANCEL request or a response including 
a failure indication from the network the MSC Server shall act in accordance with subclause 7.2.6 in 3GPP TS 23.231 
[40] and 3GPP TS 29.232 [11]. 

7.3.2 Clearing received from the user 
7.3.2.1 Access bearer clearing 

Once the call clearing and the release of the associated radio resources have been completed, the MSC Server releases 
any CS-MGW allocated resources for the access side. If any resources were seized in the CS-MGW, the MSC Server 
uses the Release Termination procedure as specified in 3GPP TS 29.232 [1 1] to request the CS-MGW to remove the 
access side bearer termination. 
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7.3.2.2 Network side clearing 

If the MSC Server requires to release resources due to the receipt of a BYE or CANCEL request or a response including 
a failure indication from the originating or terminating UE the MSC Server shall act in accordance with subclause 7.2.6 
in 3GPP TS 23.231[40] and 3GPP TS 29.232 [1 IJ. 

7.3.3 Call clearing received from the CS-MGW 

7.3.3.1 Bearer released received on the access side 

After the MSC Server has received the Bearer Released procedure from the CS-MGW on the access side, the MSC 
Server shall release the access resources as described in 3GPP TS 24.008 [3]. If the call is already established towards 
the network side, call clearing to the network side is performed as described in subclause 5.5.3. 

7.3.3.2 Bearer released received on the network side 

After the MSC Server has received the Bearer Released procedure from the CS-MGW on the network side, the MSC 
Server shall clear the call to the network side as described in subclause 5.5.3 and clear the call to the UE as described in 
3GPPTS 24.008 [3]. 

7.4 Call independent procedures 

The MSC Server and the CS-MGW are involved in a number of procedures which are not related to the setting up and 
clearing of calls. The MSC Server and the CS-MGW shall comply with the requirements stated in the different 
subclauses 10.1 - 10.10 of 3GPP TS 23.205 [39] and subclauses 10.12 - 10.16 of 3GPP TS 23.205 [39]. 

7.5 Explicit Congestion Notification 

An MSC Server and a CS-MGW may support Multimedia Telephony using Explicit Congestion Notification (see IETF 
RFC 3168 [48], IETF draft-ietf-avtcore-ecn-for-rtp [49], and 3GPP TS 26.114 [28]), and may then act as an ECN 
endpoint to enable ECN with a local ECN-capable terminal within a local network that properly handles ECN-marked 
packets. 

The ECN procedures described in 3GPP TS 29.163 [46], Clause 9.2.11, for MGCF and IM-MGW are then applicable for 
MSC Server and the CS-MGW. 
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